Does Javascript pass by value or pass by reference?

Javascript exhibits quite interesting behavior when it passes object parameters. At first glance, it would appear that it passes everything by reference. Consider the following HTML page.

<html>
<body>
<script type="text/javascript">

    function MyObject() {
        this.value = 5;
    }

    var o = new MyObject(); 
    alert(o.value); // o.value = 5

    function ChangeObject(oReference) {
        oReference.value = 6;
    }

    ChangeObject(o);
    alert(o.value); // o.value is now equal to 6

</script>

</body>
</html>

We initialize an object o by calling the MyObject() constructor. The constructor sets the value member to 5. We then pass o into the ChangeObject() function, where it sets the value member to 6. If o were passed by value, that would mean we are passing a copy of o, and that its value member would not be changed once the function exits. However, if we open up this HTML page in a browser, the final alert(o.value) indeed prints 6. This would lead us to conclude that Javascript passes by reference.

However, things get really interesting when we look at this HTML page.

<html>
<body>

<script type="text/javascript">

    function MyObject() {
        this.value = 5;
    }

    var o = new MyObject();    
    alert(o.value); // o.value = 5

    function ChangeObjectWithNew(oReference) {
        oReference = new MyObject();
        oReference.value = 6;
    }

    ChangeObjectWithNew(o);
    alert(o.value); // o.value is still 5

</script>

</body>
</html> 

This page is identical to the last, with the slight modification that we call the ChangeObjectWithNew () function. ChangeObjectWithNew creates a new instance of MyObject and assigns it to oReference, and then sets this new instance’s value member to 6. If Javascript passed by reference, o would now point to this new instance, and its value member would be 6 after ChangeObjectWithNew ran. However, if you run this page in a browser, the final alert(o.value) still prints 5. How is this possible?

What is happening behind the scenes is that Javascript is passing a reference of o by value. This can be a little confusing, so think of it this way. When o is first declared and initialized, it points to the memory location of the actual object that we instantiated. When the ChangeObject function is called, it passes in a copy of this pointer that points to the exact same memory location. Thus any changes to oReference’s member variables will be reflected in o, since both point to the same spot in memory. However, when we call ChangeObjectWithNew, the line “oReference = new MyObject” now causes to point to an entirely different spot in memory. Thus any further changes to oReference’s member variables will no longer be reflected in o.

A picture helps clarify things.

Here is what the situation looks like when we call ObjectChangeWithNew:

After ChangeObjectWithNew has run, note that oReference now points to a new memory location.

Since Javascript hides the implementation details behind how it handles its pointers, this C program demonstrates passing by reference and passing a “reference” by value. ChangeObject is called with a pointer to MyObject. This is passing by reference. ChangeObjectWithNew is being called with a copy of the original MyObject pointer. As a result, modifying its value member does not modify the original pointer’s value member.

#include <stdio.h>
#include <stdlib.h>

typedef struct 
{
    int value;
} MyObject;

void ChangeObject(MyObject * objReference)
{
    (*objReference).value = 6;
}
 
MyObject * ChangeObjectWithNew(MyObject * objReference)
{
    objReference = (MyObject *)malloc(sizeof(MyObject));
    objReference->value = 6;
}

int main(int argc, char* argv[])
{       
    MyObject * o = (MyObject *)malloc(sizeof(MyObject));  
    MyObject * oCopy;  //this will be a copy of the original object pointer      
    oCopy = o;

    printf("Setting o->value to 5");
    o->value = 5;
    printf("MyObject.value: %d\n", o->value);
    
    //now pass by reference
    printf("Calling ChangeObject with original pointer\n");
    ChangeObject(o);  //this will change o->value to 6    
    printf("MyObject.value: %d\n", o->value);  //prints 6

    //reset o->value to 5
    printf("Resetting o->value to 5\n");
    o->value = 5;
    printf("MyObject.value: %d\n", o->value);  //prints 5

    //now pass a COPY of the origal pointer
    //this is how Javascript behaves, minus the memory leak
  
    printf("Passing in a copy of the pointer o to ChangeObjectWithNew\n"); 
    oCopy = ChangeObjectWithNew(oCopy);
    printf("MyObject.value: %d\n", o->value); //still prints 5

    //free the memory 
    free(o);
    free(oCopy);
    o = NULL;
    oCopy = NULL;

    scanf("Press any key to continue");
}

The fact that Javascript passes a “reference” by value is important to keep in mind. Assuming it passes by reference can lead to some difficult to track down bugs later on.

Dynamically modifying client endpoints in WCF

I was doing some contract work for a client building out a SOA backend for them. It consisted of some WCF services that all talked to one another. Due to how the client had set up their deployment process, we had to dynamically load these client endpoint address from an external XML file at runtime, instead of setting them inside the web.config.
In other words, we needed a way to dynamically change the address attribute:

<system.serviceModel>
    <client>
        <endpoint address="http://someaddress.com/webservice"
          binding="ws2007HttpBinding" bindingConfiguration="WebService_ws2007HttpBinding"
          contract="WebService.ServiceContracts.IWebService" name="ws2007HttpBinding_IWebService" /> 
    </client> 
</system.serviceModel> 

WCF allows you to programmatically configure any System.ServiceModel setting in the web.config, so the challenge was to inject the endpoint before the call was actually made. Normally, you can pass in the endpoint address to the channel factory constructor and be done with it. However, the service in question we needed to modify was a simple passthrough WCF router. There was no code to speak of, so in order to modify the client endpoints we decided to do so in a service behavior.

The first task was to figure out how to access the endpoints themselves. At first, I tried:

    var serviceModelSection = ConfigurationManager.GetSection("system.serviceModel"); 
    ClientSection clientSection = serviceModelSection.GetSection("client" ) as ClientSection;
    ChannelEndpointElementCollection endpointCollection = clientSection.Endpoints;

However, when I actually tried to edit the endpoints inside ChannelEndpointElementCollection, I got an error: “The configuration is read only”. After searching online, I tried using WebConfigurationManager.OpenWebConfiguration instead:

       Configuration webConfig = WebConfigurationManager.OpenWebConfiguration("~" );
       ClientSection clientSection = webConfig.GetSection("system.serviceModel/client" ) as ClientSection;
       ChannelEndpointElementCollection endpointCollection = clientSection.Endpoints;

       //dynamically load the URI here
       Uri serviceAddress = “http://sometempuri.org”;

       endpointCollection[0].Address = new EndpointAddress(serviceAddress);         
       webConfig.Save();

This option was a non starter because webConfig.Save() literally saves the actual web.config file itself. This causes the application pool to recycle, and since it edits the physical file, the changes made won’t apply to the current request.

Ultimately, we ended up implementing IEndpointBehavior interface. The IEndpointBehavior interface has an ApplyClientBehavior method, that takes as its parameter a client service endpoint. This method fires only once for the lifetime of the application for each client endpoint defined, which is exactly what we wanted. The following sample code demonstrates how this service behavior can be used to dynamically set the EndpointAddress for the client endpoint.

public class WebServiceEndpointBehavior : IEndpointBehavior
{
    public void Validate(ServiceEndpoint endpoint)
    {
           
    }

    public void AddBindingParameters(ServiceEndpoint endpoint, BindingParameterCollection bindingParameters)
    {
    
    }

    public void ApplyDispatchBehavior(ServiceEndpoint endpoint, EndpointDispatcher endpointDispatcher)
    {
           
    }

    public void ApplyClientBehavior(ServiceEndpoint endpoint, ClientRuntime clientRuntime)
    {           
        Uri serviceAddress = new Uri("http://sometempuri.org ");   //dynamically load URL here
            endpoint.Address = new EndpointAddress(serviceAddress);       
    }                                                
}        

From here, it was just a matter of coding the behavior extension element that loads the behavior, as well wiring in this extension element into the web.config. Here are the relevant snippets:

namespace WebService
{
    public class WebServiceEndpointBehaviorExtensionElement: BehaviorExtensionElement
    {
        protected override object CreateBehavior()
        {
            return new WebServiceEndpointBehavior ();
        }

        public override Type BehaviorType
        {
            get { return typeof (WebServiceEndpointBehavior ); }
        }
    }
}
  <endpointBehaviors>
        <behavior name="updateEndpointAddress">
          <webserviceEndpointBehavior/>
        </behavior>
<extensions>
    <behaviorExtensions>
        <add name="webserviceEndpointBehavior" type="WebService.WebServiceEndpointBehaviorExtensionElement, WebService" />
    </behaviorExtensions>
</extensions>

CredentialCache.DefaultNetworkCredentials is empty and so is Thread.CurrentPrincipal.Identity.Name

I was working on a simple console application in C# that issued HTTP DELETE requests to WebDAV to delete expired documents from the file system. Once completed, this was to run periodically as a job. However, I kept getting back 401 Unauthorized on the DELETE requests. While troubleshooting the issue, I went down the rabbit hole and learned some interesting things. I was passing in CredentialCache.DefaultNetworkCredentials as my HttpRequest credentials. So as a sanity check, I tried viewing it in the debugger to make sure the program was passing in my credentials, only to find that CredentialCache.DefaultNetworkCredentials.UserName was blank.

Well, it turns out that you can’t actually view the credentials unless you set them manually yourself. According to the MSDN documentation:

“The ICredentials instance returned by DefaultCredentials cannot be used to view the user name, password, or domain of the current security context.”

So I tried checking the value of Thread.CurrentPrincipal.Identity.Name instead. This was blank as well. Upon further reading, I determined that this was due to the principal policy not being explicitly set to WindowsPrincipal. Once I did so, Thread.CurrentPrincipal.Identity.Name correctly displayed my windows login ID:

AppDomain.CurrentDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal);
Console.WriteLine(Thread.CurrentPrincipal.Identity.Name);

It is helpful to review what an application domain is before proceeding. In Windows, every application runs as its own process, complete with its own set of resources. By isolating applications via processes, this minimizes the risk that one badly coded application can negatively impact others. In the Common Language Runtime, application domains provide an even more granular level of isolation. A single process (the application host) can run multiple application domains, each with the same level of isolation that separate processes would have, minus any of the overhead.
Because every app domain is separate from one another, each has its own Principal object. This object represents the current security context that the code is running as. The PrincipalPolicy is an enum that indicates how this principal object is to be created for the given app domain. Setting it to WindowsPrincipal will map the principal object to the Windows user that the application host is executing as. By default, the PrincipalPolicy will be UnauthenticatedPrincipal, which will set Name to empty string.

After doing some more digging, I also found out that I could use WindowsIdentity.GetCurrent().Name to determine what user the program was executing as:

Console.WriteLine(WindowsIdentity.GetCurrent().Name); 

Having finally proven to myself that my program was running as the correct user, I eventually figured out the issue. It was completely unrelated to the code of course; I had simply forgotten to enable Windows Authentication in IIS. I didn’t mind the time sink, as it proved to be quite educational.

A no frills AJAX uploader using ASP.NET and vanilla javascript

This is a tutorial on how to write a simple AJAX uploader. I’ve been doing more front end development at work lately, and I recently needed to write a page that processed a small file upload from the user. Because the page in question only accepted files up to 1 MB in size, I figured it would be a much better user experience to do the upload via AJAX, rather than forcing the user to sit through an entire FORM post and wait for the page to reload. Normally, I’d consider going with a third party solution, as there are quite a few AJAX uploaders available on the web. However, management wanted to reduce dependencies on third party code. This sounded reasonable to me. The files in question were going to be small, so fancy features such as progress bars that are commonly found in AJAX uploader plugins would prove to be unnecessary anyway. As a bonus, I’d get to avoid the hassle of researching all the available options out there and save time spent reading through pages of boring documentation. All in all, I was pretty happy to go through the exercise of writing my own.

The first roadblock that I encountered is the fact that Javascript can’t actually access the file system. To see why this would be a bad idea, just look at the well intentioned yet completely awful technology that is ActiveX and all the horrible malware that it has spawned. Giving a client side scripting language like Javascript access to the file system represents a gaping security hole, so it is a good thing that it cannot. To work around this limitation, we must still do a FORM post, but through the use of some clever smoke and mirrors the user never needs to leave the page.

This is accomplished using the “target” attribute of the form element. This attribute specifies where to open the page specified by the “action” attribute. For example, you can provide the value “_blank” to tell the browser to open up the “action” page in a new window. It just so happens that you can also specify an Iframe for your target attribute. So the solution will be to add a hidden IFrame element to the HTML and then specifying it as the target attribute of the form.

The HTML is straightforward. We will have a form element, a file upload element, a hidden IFrame, and a submit button. Finally, we will have a div (with the display initialized to “none”) that displays a simple “upload in progress” message along with an animated gif of a spinning wheel.

<form id="uploadForm" action="/processupload.aspx" method="post" enctype="multipart/form-data" target="upload_target" onsubmit="startUpload();"> 	  
	<input type="file" name="picFile" runat="server" size="50">                        
	<input type="submit" name="submitBtn" value="Upload">						
</form>           	     
    
<br />  
    
<div id="result" style="display:none">Upload in progress.... please wait <img src="/images/processing_small.gif" align="absmiddle" /></div>
    
<iframe id="upload_target" name="upload_target" style="width:0;height:0;border:0px solid #fff;"></iframe> 

The Javascript code is fairly simple as well. We will have two simple functions: StartUpload and StopUpload. StartUpload will simply display our hidden div:

function startUpload() {
	$('result').style.display = "block";
}

StopUpload will be called after the server has finished processing the upload. It will either display “Upload successful” or show some error message.

function stopUpload(success) {
    var result = '';
    if (success == 1) {
        $('result').innerHTML = 'The file was uploaded successfully!';
    }
    else {
        $('result').innerHTML = 'Sorry, there was an error during the file upload.';
	   }			
    }

The final piece of the puzzle is to figure out a mechanism with which to call StopUpload after the server has finished processing the upload. Because the “target” attribute is an iframe, we can write javascript code in the server response, which will then automatically be called when the browser renders the result in the IFrame.

The following is a bare bones Page_Load() function for the processUpload.aspx specified in the form action. Obviously, a real world version would contain more robust error handling, security checks, business logic, and so on. It’d also have a more descriptive file name as well.


protected void Page_Load(object sender, EventArgs e)
{
    int success = 0;
    try
    {
	HttpPostedFile uploadedFile = Request.Files[0];

        //In the real world we'd want to pull set the upload path from web.config or something along those lines
        string imageUploadPath = "C:\\temp";  
	uploadedFile.SaveAs(imageUploadPath); 

        string iframeJavascript = "<script language="javascript" type="text/javascript" >window.top.window.stopUpload(1)</script>";
 
	Response.Write(iframeJavascript);  
    }
    catch (Exception e)
    {
        //here is where we could send back more detailed error information to the browser...
        string errorResponse= "<script language="javascript" type="text/javascript" >window.top.window.stopUpload(0)</script>"; 
	Response.Write(errorResponse);      
    }
}

Lo and behold, we now have a fully functional AJAX uploader. From here we can make any number of improvements to make it more useful. For example, if we wanted StopUpload to display a more useful error message, we could add an “ErrorMessage” parameter to the javascript function, and have the server write out appropiate messages based on the nature of the error: “File size too large”, “Error processing file”, and so on. Of course, if you find yourself spending too much time implementing, testing, and debugging additional functionality, it would make more sense to use the many AJAX uploader plugins already out there on the internet (many of them free).

Manipulating raw bitmap data in .NET

The Bitmap class found in the .NET Framework provides a lot of useful functionality.   Unfortunately, it doesn’t have any methods that let you easily manipulate the raw bitmap data.   It provides a SetPixel method which takes x,y coordinates and a color value, and does exactly what you’d think it would.    Unfortunately, the implementation is not the most efficient.   It will lock the entire bitmap before modifying the data.    This is fine if you only need to manipulate a few pixels, but horrible if you need to manipulate the entire image.   Needless to say, the overhead of locking and unlocking the data just to modify one measly little pixel is detrimental for performance.

I found a few articles on the best way to manipulate the raw data.    The simplest and most intuitive way is to create a memory stream, save the bitmap to it, and then manipulate the bytes in the memory stream.     Once you are done, you recreate the bitmap based on the modified memory stream.   For example, this pedeantic snippet sets all the bits in the bitmap purple (based on this tutorial article):

MemoryStream ms = new MemoryStream();

bmp.Save(ms, ImageFormat.Bmp);
byte[] bitmapData = ms.GetBuffer();

const int BITMAP_HEADER_OFFSET = 54;
Color colorValue = Color.Purple;

for (int i = 0; i < bitmapData.Length; i += 4)
{
    bitmapData[BITMAP_HEADER_OFFSET + i] = colorValue.R;
    bitmapData[BITMAP_HEADER_OFFSET + i + 1] = colorValue.G;
    bitmapData[BITMAP_HEADER_OFFSET + i + 2] = colorValue.B;
    bitmapData[BITMAP_HEADER_OFFSET + i + 3] = colorValue.A;
}

bmp = new Bitmap(ms);

Once you have the bytes themselves you can begin manipulating them.      Each pixel is represented by a four bytes, consisting of the Red, Green, Blue, and Alpha (this controls transparency) values, respectively.     Divide the current byte index by four to get the pixel you are on.    From there you can mod by the bitmap width to get the x coordinate, and divide by the bitmap height to get the y coordinate.

One thing to note is that the raw image data does not begin at byte 0.     The first 54 bytes of the data consists of the bitmap header which contains various metadata. The problem with this code of course, is that it hard codes this offset and assumes it will never change.    This ties the code to the internal implementation details of the Bitmap class which violates encapsulation.   Not the best practice.

So another way of accomplishing the same task that does not require knowledge of the internal structure of a windows bitmap is to pin the bitmap object in memory and copy the data over to a local buffer. The data can then be manipulated locally and then copied back to the bitmap, which can then be unpinned from memory.    The following is based on the MSDN example.

// Lock the bitmap's bits.
Rectangle rect = new Rectangle(0, 0, bmp.Width, bmp.Height);
System.Drawing.Imaging.BitmapData bmpData =
bmp.LockBits(rect, System.Drawing.Imaging.ImageLockMode.ReadWrite,
bmp.PixelFormat);

// Get the address of the first line.
IntPtr ptr = bmpData.Scan0;

// Declare an array to hold the bytes of the bitmap.
byte[] bitmapData = new byte[Math.Abs(bmpData.Stride) * bmp.Height];

// Copy the RGB values into the array.
System.Runtime.InteropServices.Marshal.Copy(ptr, bitmapData, 0, bitmapData.Length);

Color colorValue = Color.Purple;
for (int i = 0; i < bitmapData.Length; i += 4)
{
    bitmapData[i] = colorValue.R;
    bitmapData[i + 1] = colorValue.G;
    bitmapData[i + 2] = colorValue.B;
    bitmapData[i + 3] = colorValue.A;
}

// Copy the RGB values back to the bitmap
System.Runtime.InteropServices.Marshal.Copy(bitmapData, 0, ptr, bitmapData.Length);

// Unlock the bits.
bmp.UnlockBits(bmpData);

Note the use of the Bitmap data class, particularly the use of Scan0 and Stride.   Scan0  gets the memory location of the actual image data itself, completely bypassing the problem of figuring out the end of the bitmap header.    Stride represents the width in bytes of a bitmap object.

The Lock and UnlockBits are used to pin the bitmap object in memory.     What this means is that this object now has a fixed location in memory and cannot be moved.    Typically, the garbage collector moves objects around during the lifetime of an application.    This is done to avoid memory fragmentation.   For example, the garbage collector has a compaction phase where objects that are still being referenced are packed together in the heap.      This solves the problem of being unable to allocate a block of memory even though there is enough free memory (imagine for example, that there is 3KB of free memory, but a 3KB block cannot be allocated because the 3KB is not contiguous and is spread out in small chunks throughout the heap) Pinning the bitmap allows us to safely copy the data back and forth from the object without having to worry whether or not that memory location is still the correct address.

To test the performance, I wrote a simple program to set all the pixels in a 1000 x 1000 bitmap to purple.      The pinning method is slightly faster, but not by much.   Here is the code:

using System;
using System.Drawing;
using System.IO;
using System.Drawing.Imaging;

namespace BitmapTestFramework
{
    class Program
    {
        static void Main(string[] args)
        {
            Bitmap testBitmap = new Bitmap(1000, 1000);
            DateTime start;
            DateTime end;
            TimeSpan timeSpan;

            Console.WriteLine(string.Format("Method 1:   Calling Get/Set Pixel", testBitmap.Width, testBitmap.Height));
            start = DateTime.UtcNow;
            Method1(testBitmap);
            end = DateTime.UtcNow;
            timeSpan = end - start;
            Console.WriteLine(string.Format("Completed in {0} milliseconds", timeSpan.TotalMilliseconds));

            Console.WriteLine("Method 2:  Create a memory stream of the bitmap and manipulate the buffer");
            start = DateTime.UtcNow;
            Method2(testBitmap);
            end = DateTime.UtcNow;
            timeSpan = end - start;
            Console.WriteLine(string.Format("Completed in {0} milliseconds", timeSpan.TotalMilliseconds));

            Console.WriteLine("Method 3:   Pin the bitmap object in memory and manipulate a local copy of the data");
            start = DateTime.UtcNow;
            Method3(testBitmap);
            end = DateTime.UtcNow;
            timeSpan = end - start;
            Console.WriteLine(string.Format("Completed in {0} milliseconds", timeSpan.TotalMilliseconds));
        }

        static void Method1(Bitmap bmp)
        {
            for (int x = 0; x < bmp.Width; x++)
            {
                for (int y = 0; y < bmp.Height; y++)
                {
                    bmp.SetPixel(x, y, Color.Purple);
                }
            }
        }

        static void Method2(Bitmap bmp)
        {
            MemoryStream ms = new MemoryStream();
            bmp.Save(ms, ImageFormat.Bmp);
            byte[] bitmapData = ms.GetBuffer();

            const int BITMAP_HEADER_OFFSET = 54;

            Color colorValue = Color.Purple;
            for (int i = 0; i < bitmapData.Length* 4; i += 4)
            {
                bitmapData[BITMAP_HEADER_OFFSET + i] = colorValue.R;
                bitmapData[BITMAP_HEADER_OFFSET + i + 1] = colorValue.G;
                bitmapData[BITMAP_HEADER_OFFSET + i + 2] = colorValue.B;
                bitmapData[BITMAP_HEADER_OFFSET + i + 3] = colorValue.A;
            }

            bmp = new Bitmap(ms);
        }

        private static void Method3(Bitmap bmp)
        {
            // Lock the bitmap's bits.
            Rectangle rect = new Rectangle(0, 0, bmp.Width, bmp.Height);
            System.Drawing.Imaging.BitmapData bmpData =bmp.LockBits(rect, System.Drawing.Imaging.ImageLockMode.ReadWrite, bmp.PixelFormat);

            // Get the address of the first line.
            IntPtr ptr = bmpData.Scan0;

            // Declare an array to hold the bytes of the bitmap.
            byte[] bitmapData = new byte[Math.Abs(bmpData.Stride) * bmp.Height];

            // Copy the RGB values into the array.
            System.Runtime.InteropServices.Marshal.Copy(ptr, bitmapData, 0, bitmapData.Length);

            Color colorValue = Color.Purple;
            for (int i = 0; i < bitmapData.Length; i += 4)
            {
                bitmapData[i] = colorValue.R;
                bitmapData[i + 1] = colorValue.G;
                bitmapData[i + 2] = colorValue.B;
                bitmapData[i + 3] = colorValue.A;
           }

            // Copy the RGB values back to the bitmap
            System.Runtime.InteropServices.Marshal.Copy(bitmapData, 0, ptr, bitmapData.Length);

             // Unlock the bits.
             bmp.UnlockBits(bmpData);
        }
    }
}

Here is the output on my machine:

Method 1:   Calling Get/Set Pixel
Completed in 649.414 milliseconds
Method 2:  Create a memory stream of the bitmap and manipulate the buffer
Completed in 91.7969 milliseconds
Method 3:   Pin the bitmap object in memory and manipulate a local copy of the data
Completed in 82.0312 milliseconds