x86 and ia64 and x64, oh my!
With the .NET Framework 2.0 now supporting 64-bit platforms, I have begun work on upgrading our patch build system to handle 64-bit patches. It’s been quite an adventure down the yellow-brick road of 64 bitness that I think is worth sharing.
Why does the .NET Framework need to support 64-bit platforms, though? While most IL modules embedded in assemblies – which are still PE/COFF executables – are architecturally agnostic some are not, like CustomMarshalers.dll or mscorelib.dll. In these cases both 32- and 64-bit assemblies are required. Because 32-bit code will run under 64-bit Windows under Windows-on-Windows 64 (WOW64) 32-bit processes still may need access to the 32-bit assemblies either in the GAC or in the Framework version directory (ex: %windir%Microsoft.NETFrameworkv2.0.nnnn). For code running natively under 64-bit Windows, access to 64-bit assemblies is necessary. These files are installed side by side. If you have .NET 2.0 installed and look in %windir%assembly you’ll see a new column in the shell view that tells you if the assembly is MSIL, x86, or AMD64 or IA64. Future versions should, by the way, should replace “AMD64” with “x64”.
So what is difference between x86, AMD64, IA64, and x64? x86 is what most everyone is running now – 32-bit processes on 32-bit Windows. AMD64 is Advanced Micro Devices, Inc.’s answer to 64-bit computing that runs 32-bit code natively as well. This means that you can install 32-bit Windows on an AMD64 machine. These machines have already begun shipping with 32-bit Windows XP and a friend of mine in MN is already running one happily. IA64 – or Intel Itanium – processors run 64-bit natively and offer 32-bit emulation, but you cannot install 32-bit Windows on it. You need to run Windows Server 2003 for 64-bit Itanium-based Systems. Intel has also introduced EM64T – or Extended Memory 64 Technolocy – for Intel Xeon processors. This processor also supports running 32-bit processes natively like the AMD64.
x64 is the term Microsoft uses to collectively refer to processors that run both 32- and 64-bit code natively without emulation – both AMD64 and EM64T. There are flavors of both Windows XP and Windows Server 2003 that currently run on x64 which is poised to become the predominant 64-bit computer technology it would seem.
So patches need to come in three flavors: x86, ia64, and x64. The latter two patches will contain both 32- and 64-bit binaries for the reasons given above and will be larger in size. While normally x86 code would run under WOW64 on 64-bit systems, the 32-bit release setups and patches will block on 64-bit systems (at the time this was published) to make sure that both 32- and 64-bit binaries are present.
To decrease patch size and present a better end-user experience, we are looking to implement a 32-bit native wrapper for all three architectures. OS detection will be used in conjunection with the MSI Template summary property of the MSI package embedded in the native executable to present a more user-friendly error message if a user accidentally downloads and tries installing a 64-bit patch on a 32-bit system. Currently, the Windows executable loader would simple display, “<file> is not a valid Win32 application.” This works because the 32-bit MSI APIs can install a 64-bit MSI package or patch using the 64-bit Windows Installer service, so no file system or registry redirection will occur.
Updated: The 4th paragraph mistakenly stated that x64 refers to both AMD64 and IA64. This was supposed to have read EM64T, not IA64.
Light
Dark
0 comments