Galin Iliev's blog

Software Architecture & Development

x64bit Development with .NET

Today the hardware is cheap (and getting cheaper) so it is easily affordable to have multiple quad code CPUs, 8 GB RAM and more. In order to fully utilize this hardware x64b OS is needed and Windows has x64b editions for a while.

But what happens with the software we write?! if you use managed code only then is easy – IJW – It Just Works (do you remember that term for compiling unmanaged code C++ into IL? well that’s different)

As MSDN article “Migrating 32-bit Managed Code to 64-bit” says

Consider a .NET application that is 100% type safe code. In this scenario it is possible to take your .NET executable that you run on your 32-bit machine and move it to the 64-bit system and have it run successfully. Why does this work? Since the assembly is 100% type safe we know that there are no dependencies on native code or COM objects and that there is no 'unsafe' code which means that the application runs entirely under the control of the CLR. The CLR guarantees that while the binary code that is generated as the result of Just-in-time (JIT) compilation will be different between 32-bit and 64-bit, the code that executes will both be semantically the same. (You cannot install the .NET Framework version 2.0 on Windows 2000. Output files produced using .NET Framework versions 1.0 and 1.1 will run under WOW64 on a 64-bit operating system.)

If you want to dig into x64 vs x86 differences read Scott Hanselman’s article “Back to Basics: 32-bit and 64-bit confusion around x86 and x64 and the .NET Framework and CLR

Also check Brian Peek’s blog post on the subject

Comments (1) -

  • Anton Staykov

    2/17/2009 7:34:02 AM | Reply

    Interesting story. I personally think that Vista & 2008 Server & Windows 7 should have had only x64 versions. Come on, the youngest x86 CPU is (as far as I think) Intel Pentium III. All generations after it are x64.
    Anyway, I've been developing for x64 platforms and I have had some issues. It's not exactly like they say "you write the code, it just runs". What I am interested is whether there is difference in the Stack allocation mechanism when running on x64 CLR. Because, as we in a standard world on x86, there is 1 MB of memory allocated for the stack. If this is same for x64 also, then we definitely got an issue, because the pointers on x64 architecture are double in size. So if we have 1 MB of stack, it will be half the space we have on x86. And if you have a code that works with lots of object you are more likely to get StackOverflow exception. It is the situation with iTextSharp, which is a free open source library for managing PDF files. Since in a PDF world, a file generally consists of Objects, when merging vast amount of files, you will get great amount of Objects. While running on x86 architecture there might be no problems, once you move to x64 StackOverflow exceptions begin to rise. What I did in that particular case was to just force compilation for x86 platform.
    All I wanted to say is that we should care about the architecture that will run our application and do not relay on the “it will work out of the box” Smile