Archive for April 23, 2008
Recently, someone asked me to help with getting an existing Dotnet application to run on 64-bit XP. It turned out to be pretty easy, compared to the transition from 16-bit to 32-bit in the old days.
Why would you run 64-bit?
Most of the modern processor these days are 64-bit CPU, but we still live in a mostly 32-bit world. One chief reason is that 64-bit drivers are not yet available. Application compatibility is less of an issue because 64-bit windows can run 32-bit application under WOW (windows on windows). When I do see people run 64-bit OS, it is usually because they are either diehard hobbist who want the latest and greatest or they are using application that requires a large amount of memory.
DotNet under 64-bit
- Microsoft has 32-bit and 64-bit runtime for DotNet 2.0 or above. When you install the 64-bit runtime, the 32-bit runtime is also installed.
- Dotnet assemblies compile into MSIL (Microsoft Intermediate Language). MSIL can run in 32-bit or 64-bit mode.
- When you compile, you have the option to compile Any CPU, x86, x64 and Itanium. Remember that DotNet does not compile into machine specific code but into MSIL. This merely set a flag to tell DotNet which environment to run in.
- If you set the flag to any cpu, it will run in 64-bit on 64-bit machine and 32-bit on 32-bit machines.
- If you set the flag to x86 and run it on a 64-bit machine, it will run the program under WOW in 32-bit emulation mode.
- If you set the flag to x64 and run it on a 32-bit machine, you will get an exception.
- The only reason you want to set the flag is dependencies. If you reference 32-bit code within your application (such as unmanaged COM code), you will need to run the application under 32-bit mode.
- Note that DotNet 1.1 or earlier are available only in 32-bit mode. If you reference DotNet 1.1 code, you will need to run it in 32-bit mode.