X86, X64, IA64, AMD64, EM64T...

x86

Back in “good old times” Intel named processor model numbers 8086, 80286, 80386, 80486, 80586 (ok, this one didn’t really exist - Pentium was introduced instead). Since they all were pretty much same architecture, at one point somebody just said x86 processors. To make things more interesting although x86 could refer to 80286 which is 16-bit processor, we use it in current days to refer to 32-bit architecture only. Intel itself referred to it as IA-32, but that name never really sounded as good.

IA64

Intel decided to make new 64-bit processor. Since IA-32 was heavy with compatibility baggage from as far as 8086, they made a clean cut. Everything on this processor was bigger, better and incompatible with old IA-32 architecture. Since server market needed 64-bit, some advancements were made there but market penetration wasn’t as good as Intel hopped. Problem was that native applications came in small numbers while compatibility with old IA-32 (or x86) instruction set was really slow. Architecture still lives on with Itanium processor.

x64

AMD noticed problem and made own version of 64-bit processor. They just added some new 64-bit instructions to already existing x86. Solution was not all that clean as IA-64 but old applications worked at same speed (no emulation was needed) and new applications could address 64-bit space. That solution is known now as x86-64.

It took a while for Intel to see that his Itanium is going nowhere near consumer machines. When they finally took notice unbelievable thing happened - Intel used AMD64 instruction set. This made those two architectures same in sense of programming support. One doesn’t need to care whether he writes for Intel or AMD (not really true for early version of Pentiums since they lacked some instructions). Early name for Intel’s version was EM64T just in case you were interested.

64-Bit - How Hard Can It Be?

If you do programming in .NET world answer is clear: It is not hard at all. As long as you keep your hands out of cookie jar (know also as Win32), moving to 64-bit is just none to few clicks away.

Of course, some prerequisites are needed.

You need to have 64-bit operating system

This is pretty obvious - 32-bit operating system on 64-bit hardware will work in 32-bit mode. No big surprise here.

You need to work on .NET framework 2.0 and above

.NET framework 1.0 and 1.1 exist in 32-bit versions only. They will run on 64-bit platforms without any problem but they will do so through emulation layer called WOW64 and thus no support for 64-bit address space - everything above 2 GB stays unavailable.

You need to tell your favorite .NET compiler that you want that

By default, .NET will compile code for target platform called “Any CPU”. Although one could think that this would make code that is common denominator of all - 32-bit, it will actually mark executable as both 32-bit and 64-bit. This is possible since code is translated to CLR and thus processor agnostic. On 32-bit systems it will run as 32-bit code, on 64-bit systems it will run as 64-bit code. In case that you need insane amounts of memory (for me insane is above 2 GB) all the times, you can select x64 or Itanium as your target and make your code unable to run in 32-bit mode at all.

If you use installer let him know about your bit-ness also.

If you pack your code with MSI installer, you have a problem. There is no way to tell it that your code is both 32-bit and 64-bit (Any CPU).

If you select x86 as your platform, it will install correctly on both 32-bit and 64-bit Windows but on 64-bit it will install in Program Files (x86) folder. That folder is reserved for legacy 32-bit code and having your application there sends clear signal to users that something is wrong here althought it will run as 64-bit application when you start it.

If you select x64 or Itanium as your target platform you will end up with installer that will show error message and refuse to proceed if system is 32-bit (or that other 64-bit one) even though code would run just fine.

There are two solutions. Either make separate MSI package for every platform or switch installer. Neither of these two is nice one. :(