What are the differences between .NET in 32 or 64 bit systems?

Question

Imagine a pure .NET application which do not uses COM components nor PInvoke. Does it matters if the target system is 32 or 64 bits?

Answer 1

Assuming safe code with no COM components, P/Invoke, etc. there should be no semantic difference, but performance may be impacted. Consider: More memory under 64-bit, but references are bigger. Win some, lose some.

Anyway, here are a few useful references:

• See MSDN: Migrating 32-bit Managed Code to 64-bit. Quote:

"[...] 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. [...]"

• Also see Maoni's WebLog : 64-bit vs 32-bit

• Also see Scott Hanselman's Computer Zen - Back to Basics: 32-bit and 64-bit confusion around x86 and x64

Answer 2

If the application is targetting AnyCPU, the runtime behavior will be different, in particular, the memory usage and limitations.

On 64bit, there will not be the same 32bit memory limitations (2GB max memory theoretical, but 1.2-1.6 in practice). However, all object references are twice as large, so 64bit systems will use more memory.

Also, 64bit systems often have extra registers, etc, so sometimes performance can improve slightly. This is platform specific, though.

If the application is targetting x86, it will run under WoW64 and act nearly identically to how it will act in 32bit systems.

Answer 3

Another way it can matter, apart from those identified by Reed Copsey, is if your "pure" application happens to use the System.IntPtr struct for something, or if it uses unsafe code (which isn't the same thing as P/Invoke) and pointer arithmetic.

Another big one to look out for would be calls to pretty much anything in the System.Runtime.InteropServices.Marshal class. There are all kinds of awesome ways to shoot yourself in the foot in there (extremely useful when you need it, of course).