The Basics of 64-bit Windows
|how-to | home|
This is not intended to be an exhaustive discussion of processor architectures, just a quick overview. Intel processors, starting with 80386 and all the way to Pentium, are natively 32-bit processors. They have 32-bit registers, natively process 32-bit integers and use 32-bit addresses. 32-bit address means that the processor can address 32^2 = 4,294,967,296 = 4G locations in memory. Since memory on this architecture is byte-addressable, this means that the processor, and any program executing on that processor, has a maximum of 4GB of memory to use. Specific hardware implementations may limit the amount of physical memory (by implementing a narrower address, for example). For historical reasons this is called a x86 architecture (from the legacy of 80x86 Intel processors).
In contrast, 64-bit hardware and operating system uses 64-bit registers and 64-bit addresses. 64-bit processors introduced by AMD are backwards compatible with 32-bit systems, which means that you can boot and run 32-bit systems (like Windows) on them. Intel's 64-bit Itanium requires a native 64-bit system specially built for it which, once started, can execute 32-bit applications in emulation mode. Intel's EM64T extensions follow the 32-bit compatibility path and allow booting and running of native 32-bit systems. Since AMD first introduced this architecture, it is most frequently referred to as AMD64. Alternatively it is also called an x64 architecture.
Windows NT were designed to be portable to various processor architectures. Current versions of desktop/server Windows are available for x86 (Intel, AMD), IA64 (Intel Itanium) and amd64 or x64 (AMD, Intel). Previous version of Windows were available for a number of different processors. A quick look into Windows SDK reveals such names as MIPS, Alpha AXP, PowerPC, ARM and other.
Practically all current server and desktop hardware has 64-bit capabilities. To find out, just boot a 64-bit Windows installation CD. Or, easier, use a processor information tool, for example CPU-Z (http://www.cpuid.com), and look for x86-64 or x64 instructions on AMD processors and for EM64T instructions on Intel processors. If you find them - this is a 64-bit x64 processor.
64-bit Windows is compiled as a native 64-bit system. All system modules are compiled as x64 modules. The system natively executes only 64-bit programs. 32-bit programs are executed in 32-bit compatibility mode under a subsystem called WOW64 (Windows-on-Windows64). WOW64 provides an interface between 32-bit applications and the 64-bit host operating system. The same "legacy support" task of running 16-bit applications on 32-bit Windows was performed by WOW: Windows-on-Windows.
Designers of 64-bit Windows needed to make some tough choices. For example what should be the name of the directory that contains system modules. In 16-bit Windows it was called System. In 32-bit Windows it is called System32. By extrapolation we would expect System64? Ultimately the decision was made to keep the System32 name. The good folks in Redmond figured out that the migration path to the 64-bit world will be much easier for the millions of Windows applications, if the name is not changed.
Another choice was whether to provide a thunking mechanism where 32-bit modules could call 64-bit modules and vice versa? Such mechanism was used during the migration from 16-bit to 32-bit. The answer is: no. There is no way for a 32-bit module and a 64-bit module to coexist in the same process.
For the purpose of side-by-side we need to note:
processorArchitecture="amd64"is introduced in side-by-side manifests.
The conclusions are that you cannot mix 32-bit COM DLLs and 64-bit COM DLLs and that you need to run on 64-bit Windows to extract COM information from 64-bit COM DLLs