Interop with unmanaged code raises a challenge on 64-bit systems. Whether you’re using COM components such as ActiveX controls, or plain old unmanaged DLLs, you need to be aware of whether the code you wish to use is 32-bit or 64-bit; you need to know its bitness, as it’s sometimes called. If you ignore this issue, there’s a risk that your code will not work on 64-bit versions of Windows.
In general, it’s not possible for a single piece of machine code to
execute successfully in both 32-bit and 64-bit environments—you need
different binary code. The 64-bit Intel Itanium has a CPU architecture
that is a radical departure from the x86 system used in 32-bit Windows—the
machine understands an entirely different set of instructions in 64-bit
mode. The more popular x64 architecture you’ll find in most 64-bit PCs has
a lot more in common with its x86 predecessor, but even so, you need
different binary in 32-bit and 64-bit modes. The only reason existing
32-bit applications can run at all on 64-bit versions of Windows is that
64-bit Windows can host 32-bit processes. (You can see which these are in
the Windows Task Manager’s Processes tab—the 32-bit processes all have
*32 in the Image Name column.
Obviously, you’ll see this only if you’re running 64-bit Windows, as the
information would be redundant on a 32-bit system.) Windows puts the CPU
into a different mode for these processes—its 64-bit features are hidden,
enabling legacy 32-bit code to run.
Despite this, .NET ...