Moving from 32-bit to 64-bit development, need clarification regarding .net framework and platform

Question

Hello,

Quick background: I develop C# in VS2008 under .net 3.5 on a Vista-x64 machine

I recently switched to Vista-x64 and after some searching, I still feel that I do not completely understand interplay between OS and the .net framework. I would like some correction/clarification regarding this.

The following is my understanding of the development process (please correct if I am mistaken):

When I setup my project, I can set the platform target: x64, x86, AnyCpu. As I understand, AnyCpu will target the current platform (in my case x64). I can also target x86 and still execute it (due to WoW64).

I assume when I target x64, the program will use the 64-bit .net framework 3.5, and similarly 32-bit framework for x86. Is this correct?

What confuses me is when I target x64 and print out the platform information, it prints "WIN32NT". This leads me to believe "WIN32NT" is not what I think it is, but I have not been able to find out much about this. What is this?

ComputerInfo computerInfo = new ComputerInfo();
Console.WriteLine("{0,-30}:\t{1}", "Platform", computerInfo.OSPlatform);

Thanks.

Answer 1

It doesn't really help, but all the environments return win32nt... it'd be helpful if they'd return win64nt wouldn't it?

Are you finding any other problems? Or just seeking knowledge here?

Try checking your IntPtr size. It'll let you know if your app is running in 64 bit mode (I think)

http://msdn.microsoft.com/en-us/library/system.intptr.size.aspx

http://blogs.msdn.com/kstanton/archive/2004/04/20/116923.aspx

Answer 2

AnyCpu does not target the current developer platform. It target any cpu as it says. The JIT compiler running on the target machine will compile the IL into the 32bit or 64bit instructions set according to the target machine operation system. This means that .Net assembly compiled as AnyCpu will run on both 32 and 64 bit platform.

Answer 3

IIRC, Win32 is regarded as the name for the Windows API, and Win32NT is the name of the API/platform for all Windows versions derived from Windows NT. And Windows 95 is not Win32NT, because the NT and 9x API's were closely related and mostly compatible, but not the same. Also, the Win32NT API is the same on both x86 and x64 (and Itanium, which is a very different beast from x64).

Since the introduction of 64 bit Windows, 32 is no longer a reference to the processor architecture or to the size of the pointers. (In fact, Win32 also worked on Alpha machines in the early days, so Win32 is definitely not meant as Windows for x84.)

If you want to know whether you're on 32 or 64 bit, you could ask for the size of an IntPtr with

IntPtr.Size // 4 when running as x84, 8 when running on x64 or Itanium

Although strictly speaking, that's not exactly what you asked for.

Answer 4

Typically you will want to target AnyCPU - AnyCPU runs in the "native" mode of the target system. If you start you application on a 32 bit machine it will run in 32bits, if you start in on a 64bit system it will run in 64bits.

The only reason to use one of the other settings is a specific need to run in 32 or 64 bits. This will happen if you use a library that has specific requirements. For example this SQLITE library contains unmanaged code. When I used it in an application that was compiled to AnyCPU that application ran fine on a 32 bit system, but could not load the library on a 64 bit system. The reason is the unmanaged code in Sqlite library being compiled to 32 bits. Even in .net you can't mix 32 and 64 bit assemblies.

In that case the correct solution was to explicitly compile to x86 (this is a small tool that would not gain from running in 64 bits). So my application runs as a 32bit application even on a 64bit Windows.

Another possibilty would be to keep the application compiled to AnyCPU but handle the different platforms explicitly, for example by delay-loading the correct unmanaged assembly.

Other than such effects with unmanaged code I believe it is largely irrelevant which framework an application is compiled for. Only extreme counterexamples come to mind, maybe you might want to compile an application to x64 that requires an insane amount of RAM. But the typical run-off-the-mill .net application will not care what processor and what mode it is run under. But if you WANT to find out, you can always check the size of IntPtr as suggested in the other answers.