Windows & the World of 64-Bit Computing

Greater performance and more memory

Vikram is a software designer/specialist for Hewlett-Packard GDIC. He can be contacted at [email protected].

64-bit computing is moving into the mainstream and will gradually replace 32-bit computing. This shift will have a major impact on software in its current form. Among other things, the shift will require porting applications and rewriting system software, including the operating system. In this article, I examine the structure of what will likely be major players in the 64-bit software world—64-bit Windows and the 64-bit version of the Common Language Runtime (CLR). Along the way, I point out some of the advantages of moving to 64-bit platforms.

While 64-bit processors have been around for some time, their adoption has been gradual, mainly due to the lack of software to run on them. To take full advantage of 64-bit processors, the software needs to be built for 64-bit microprocessors—this cannot happen overnight. More recently, however, 64-bit processors are picking up momentum because of a combined effort on the part of both software and hardware vendors.

Early last year, for instance, we saw the arrival of 64-bit processors from Intel and Advanced Micro Devices (AMD)—the Intel Itanium based on IA-64 architecture from Intel, and AMD Opteron and AMD Athlon64 based on x86-64 architecture from AMD, respectively. Moreover, additional developments have occurred since the beginning of last year. For one thing, AMD has emerged a leader in 64-bit microprocessor sales. Second, Hewlett-Packard has also embraced the AMD processors and the AMD Opteron-based HP ProLiant Servers are now available. Also, Intel has announced its own equivalent of x86-64 in the form of Intel EM64T (Extended Memory 64 Technology).

Microsoft Windows 64-Bit Edition

On the software side, Microsoft has been working on a 64-bit version of Windows—Windows XP Professional x64 Edition for the desktop (http://www .microsoft.com/windowsxp/64bit/evaluation/upgrade.mspx), and Windows Server 2003 x64 Edition and Windows Server 2003 for servers (http://www.microsoft.com/windowsserver2003/64bit/x64/trial/ default.mspx).

The advantages of 64-bit Windows over 32-bit Windows include an increase in performance and scalability (since the 64-bit processor is capable of processing more data per clock cycle), faster performance and better accuracy of numeric calculations, and the capability to address more memory. Addressing more memory means that a single machine can support more users than its 32-bit counterpart. This means that the total cost of ownership reduces because a single machine supports more users and more applications than before, which reduces the number of servers required for an organization to run its business.

However, for Windows 64-bit to be successful, it needs to ensure that current 32-bit applications are supported. Consequently, the migration from 32-bit to 64-bit will take time, during which both 32-bit and 64-bit applications need to work side by side. To support this shift, Windows 64-bit edition includes a subsystem known as "WOW64."

WOW64

WOW64, short for "Windows-32-on-Windows-64," is responsible for providing two levels of support for 32-bit legacy applications.

First, the system files in Windows x64 Edition are not present on just the Windows\System32 folder, but split into two folders to separate the 32-bit applications from the 64-bit applications. The WOW64 subsystem intercepts calls from a 32-bit legacy application and redirects it to the Windows\SysWow64 folder; see Figure 1. If the call is from a 64-bit application, then the call is routed to the Windows\System32 folder and does not involve the WOW64. What's notable here is that Microsoft has retained the name System32 for the folder, which hosts the 64-bit system files. Figure 2, a snapshot from a system running Windows Server 2003 x64 Edition, highlights the classification of the Program Files folder into Program Files, which stores 64-bit applications and Program Files(x86), which stores 32-bit legacy applications.

Second, the WOW64 subsystem also provides redirection at the Registry level; see Figure 3. If the call is from a 32-bit application, then the call to access the HKLM\Software registry hive is intercepted by the WOW64 subsystem and redirected to the HKLM\Software\Wow6432Node. If the call is from a 64-bit application, then it is routed to the HKLM\ Software node. Figure 4, the Registry from a system running Windows 2003 Server x64 Edition, shows the Wow6432Node.

Although the compatibility has been achieved with respect to 32-bit applications, the same is not true regarding device drivers. The 64-bit edition requires 64-bit native drivers for all devices that are part of the system.

64-Bit Common Language Runtime

For 64-bit platforms to gain widespread acceptance, there must be widespread availability of developer tools and developer platforms. Microsoft's approach has been to add 64-bit support for its core development platform—the .NET Framework.

The .NET Framework 2.0 is currently in Beta 1 and codenamed "Whidbey." This release has two versions of the Framework—one for 32-bit applications and one for 64-bit applications (http://msdn .microsoft.com/netframework/downloads/ updates/default.aspx) means that the 64-bit edition of Windows will have two copies of the runtime. The .NET Framework coupled with Visual Studio 2005 provides a platform for developing 64-bit applications. The 32-bit version of the .NET Framework will reside in the \Windows\Microsoft.NET\Framework folder, while the 64-bit version of the .NET Framework resides in the \Windows\Microsoft.NET\Framework64 Folder; see Figure 5. The configuration options for these two versions of the Framework are also listed separately in the Administrative Tools Menu; see Figure 6.

Why two frameworks? One of the widely claimed advantages of compiling to MSIL is that the Just-In-Time compilation takes care of hardware-related specifics. In this case, however, there are other factors that have to be considered, such as PInvoke (Platform Invocation Services) and COM Interop, which need special handling. It is also possible to write assemblies using Visual C++ .NET, which contains both managed and unmanaged sections. Such assemblies are referred to as "mixed-mode" assemblies or "IJW" assemblies, where IJW stands for "It Just Works." Whenever such scenarios are involved, there needs to be platform-specific code; hence the need for two frameworks, each specific to the particular platform that arises. Consequently, Microsoft ships two versions of the Framework. This concept becomes clearer when you consider the Global Assembly Cache (Figure 7). The key column to look at in Figure 7 is the one entitled "Processor Architecture," of which there are three types—x86, AMD64, and MSIL. "AMD64" is shown since this snapshot is from a machine running Windows x64 Edition. In the case of Intel Itanium-based systems, the Processor Architecture "Itanium" would replace AMD64. Processor architecture denotes the platform for which the assembly has been built.

There is only a single copy of the assemblies compiled to MSIL because MSIL is neutral to processor architecture and the same assembly works on either x86 or the AMD64 platforms without modifications. These MSIL assemblies are also referred to as "portable assemblies." For example, the System.Xml in Figure 7 has only one copy of the System.Xml, which has the Processor Architecture of MSIL.

However, assemblies that are built targeting particular processor architectures (such as x86 architecture or the AMD64 architecture) need to be present separately, with one assembly built specifically for the AMD64 architecture and one assembly built specifically for the x86 architecture. These assemblies are referred to as "platform-specific assemblies." For example, take a look at the "System.EnterpriseServices" assembly in Figure 7. There is a separate assembly for AMD64 and x86.

The Whidbey team has tried to have as many MSIL-based assemblies as possible, so that there is only one copy on disk. However, in some scenarios, it is necessary to write code that utilizes COM Interop or that is written based on some platform-specific feature, such as a pointer size. These assemblies would get into the platform-specific section of the Global Assembly Cache (GAC).

Internally, in fact, there are multiple folders maintained for storing these assemblies separately. A look at the \Windows\Assembly folder from the command line (Figure 8) shows the organization of the GAC. Table 1 describes these folders.

Common Language Runtime Changes

The Common Language Runtime (CLR) has undergone internal changes to support the move to 64-bit computing. For the most part, the changes are related to code generation, garbage collection, exception handling, and debugging.

• Code generation. The 64-bit version of the CLR needs to support development of 64-bit native applications. This means that a new Just-In-Time (JIT) Compiler had to be built for each of the new platforms, namely the IA64 and the x64 platforms for generating native code for the specific platforms.
• Garbage collection. A 64-bit processor can support more memory and break the 4-GB memory barrier that existed with 32-bit systems. Hence, the garbage collector has been tuned to support larger memory.
• Exception handling. Exception handling for 64-bit systems has been completely revamped and rewritten, while retaining the end-user experience to be the same.
• Debugging. The debugger is dependent on the code-generation and exception-handling subsystems. Because of the changes to these two subsystems, the debugger also had to undergo changes.

Development Tools

Visual Studio 2005 supports development of 64-bit applications using Visual C++ .NET, Visual C#, and Visual Basic .NET. Visual J# will not support development of 64-bit applications as part of Visual Studio 2005. Figure 9 depicts the various languages supported on Visual Studio 2005 and platforms supported by these managed languages.

The Visual Studio 2005 development environment will ship as a 32-bit application that makes use of the WOW64 system. Most features provided on the 32-bit platform are available on the 64-bit platform. A notable exception is the lack of the Edit and Continue features, which have been reintroduced for the 32-bit versions of C# and VB.NET.

Apart from Visual Studio 2005, the Windows Platform SDK contains a 64-bit compiler toolset, which includes a Visual C++ compiler for developing 64-bit applications.

Precautionary Measures

Before looking at what's involved in developing 64-bit native applications, it is worth asking, "What steps can I take today in my application to ensure that the code will be portable to 64-bit?"

It is possible to take some precautionary measures and the toolset also provides some support. For instance, the Visual C++ compiler supports the /Wp64 switch that detects portability issues that may arise from the source code being compiled.

A similar facility is being built for Visual Studio 2005 by adding support for detecting these compatibility issues at compilation. This is being achieved by adding rules to FxCop, which is now integrated with the Visual Studio 2005 IDE. Although not part of Beta 1, the final release of Visual Studio 2005 will have FxCop-based rules that cover aspects in code that could affect portability of the application.

In the case of the managed languages, these features create issues with portability:

• Interop-related code that involves COM Interop and Platform Invoke: Native 64-bit applications cannot load 32-bit COM DLLs. That is, a 64-bit process cannot transition into 32-bit code and host a 32-bit DLL within the same process. Interop between processor architectures is not possible within the same process. Consequently, when 64-bit applications have to utilize any COM DLLs, a 64-bit version of the COM DLL is required.
• In many cases, however, these COM DLLs may be third-party code to which you do not have access. In such cases, the application needs to be built to target x86 architecture, in which case it runs using the WOW64 subsystem. The other option is to host the 32-bit DLL in a separate 32-bit process and make RPC calls to this host from the 64-bit application.
• Equality comparison of floating-point numbers. It is not guaranteed that the same IL will produce the same results on 32-bit and 64-bit platforms. Hence, it is recommended that the equality comparison not be made directly on floating-point numbers. Floating-point representation on 64-bit computers is based on the IEEE-754 Standard, which allows for differences. The major impact of this is on financial applications and graphics-based applications where precision is important. Algorithms should be designed in such a way that it can handle the skewed values. (For more information, see David Goldberg's paper "What Every Computer Scientist Should Know about Floating-Point Arithmetic," http://docs.sun.com/source/806-3568/ncg_goldberg.html.)
• Explicit control of layout of a structure using the StructLayout attribute. The StructLayoutAttribute is applied to structures and classes. When it is specified as Explicit, the precise position of each member of an object in unmanaged memory is explicitly controlled. Compared to a 32-bit platform, the packing of structures is different on a 64-bit platform due to the data types used in the structure. Consequently, the use of explicit control of the layout of a structure should be avoided.
• Bitwise operations on numbers. C# provides bitwise operators, which include the bitwise AND, bitwise OR, left-shift, and right-shift operators. Bitwise operations on data types vary from 32-bit to 64-bit computers since the internal representation of the data types vary across the platforms.
• Custom Serialization. The .NET Framework provides two options for serialization—an automatic serialization that can be achieved by using the Serializable attribute, and a custom serialization that can be achieved by getting the type to implement the ISerializable interface. When the underlying serialization mechanism provided by the .NET Framework is utilized, you will not face any problems. However, when custom serialization has been implemented via ISerializable, then there's a chance that the results might vary from 32-bit platform to 64-bit platform, depending on the custom approach adopted to achieve the serialization.

Of course, there may be times when the application demands use of some of these features. In such scenarios, it is necessary to build and test a 32-bit version and 64-bit version separately.

Development Using Visual Studio 2005

Again, Visual Studio 2005 supports the development of 64-bit applications that target the platforms in Table 2. You get the same user experience with the IDE and build the application as you would any normal application, keeping in mind the previously presented guidelines.

While compiling the application, the target platform can be set on the Property Pages for the Project. The property pages include a Build tab, which lets you specify the platform. In Figure 10, for instance, the options map the compiler switch for C# and VB.NET called "/platform." For VB.NET, the same option is available in the Compile Menu on the Advanced Compiler Settings Dialog Box. The Target CPU combobox in Figure 11 allows for setting the specific CPU that the application requires.

Of course, use of a specific setting depends on the specific scenario:

• AnyCPU generates an assembly that is platform agnostic. This is the IDE's default option. An assembly compiled with the AnyCPU option can run on x86-, x64-, and Itanium-based systems without problems. The output assembly generated is based on the PE32 (Portable Executable 32-bit) format. (PE32 is the file format defining the structure that all EXEs and DLLs must use.)
• x86 is used to generate code specific for a 32-bit Intel x86-compatible processor. The generated output assembly is based on the PE32 (Portable Executable) format. The executables generated by setting this option use the WOW64 subsystem.
• x64 is used to generate code specific to 64-bit native application, which targets the x86-processor architecture. The generated output assembly is based on the PE32 {+} (Portable Executable Plus) format (this is an extension to the existing PE32 file format). These executables will run natively on a 64-bit x64 machine.
• Itanium is used to generate code specific to 64-bit native applications, which target the Itanium (IA-64) processor architecture. The generated output assembly is based on the PE32 {+} (Portable Executable Plus) format. These executables will run natively on a 64-bit Itanium machine.

Another important aspect to consider is that the application being developed may need to work on all platforms; consequently, it may not be possible to build a platform-agnostic application. In such cases, the development strategy would be to make use of preprocessor directives such as #define and #if, along with conditional compilation constants. The code that is specific to a particular target platform is wrapped by preprocessor directives along with conditional compilation constants for the particular platform; the compilation is performed specifying the particular conditional compilation constant.

The recommended conditional compilation constants are:

• _AMD64_ for code that is specific to the AMD64 platform.
• _IA64_ for code that is specific to the IA64 platform.
• •_WIN64- for code that is specific to either of the 64-bit platforms.

Under the Hood: Loading a .NET Executable

Switch settings specified are embedded in the PE32 or the PE32 {+} executable generated. The PE32 {+} format is an extension to the PE32 format and has information regarding the machine type.

With the PE32, the CLR Header contains additional flags, such as ILOnly and 32BitRequired. The ILOnly flag is set when an assembly is built with the platform set to AnyCpu. The 32BitRequired flag is set when the assembly is compiled with the platform set as x86. When the platform is set to x64 or Itanium, a PE32 {+} executable is created with information regarding machine type embedded in the output file.

The operating-system loader loads an executable based on these settings. The control flow is used by the OS Loader in loading an executable; see Figure 12.

When the executable is found to be a PE32 {+}, then the EXE is launched as a 64-bit process. If not, then the ILOnly flag is verified. If this flag is not set, then the executable is determined to be a 32-bit executable and launched using the WOW64 subsystem.

When the ILOnly flag is set, a further check is made to see if the 32bitRequired flag is set. When it is set, then the executable is launched in the WOW64 subsystem; otherwise, it is remapped as PE32+ and launched as a 64-bit application.

So Is It Faster?

A question that most people often ask with 64-bit computing is "Are 64-bit applications faster compared to 32-bit applications?" This is a common myth surrounding 64-bit technology. The answer to this question is "maybe." The reason for this answer is that the performance of applications depends on many factors, and it is not possible to make a statement claiming that 64-bit applications are faster. Computing in 64-bit technology enables newer software designs, which can exploit the larger memory that 64-bit processors support. An application that has been designed to take advantage of this larger memory will be able to outperform a similar 32-bit application.

64-Bit Momentum in the Industry

Many vendors who have products for Windows have started releasing products for the 64-bit version of Windows:

• AMD has released a performance analyzer for Windows called "AMD Code Analyst." See http://www.amd.com/ us-en/Processors/DevelopWithAMD/0,,30_2252_869_3604,00.html.
• InstallShield 10.5 supports installation of 64-bit applications. See http://www .installshield.com/downloads/installshield/ aag.pdf.
• Compuware has released its DevPartner Studio in its 64-bit form entitled "DevPartner64." See http://www.compuware .com/products/devpartner/64.htm.
• The Java 2 Platform Standard Edition 5.0 (J2SE) for the AMD64 platform is currently available as Release Candidate. See http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=jdk-1.5.0-rc-windows-amd64-JPR&SiteId =JSC&TransactionId=noreg.
• Hardware manufacturers are releasing 64-bit native drivers for their products. A complete listing can be found at http://www.amd.com/us-en/Processors/ DevelopWithAMD/0,,30_2252_875_10454,00.html.
• Games have always utilized the latest and greatest hardware; for instance: Unreal Tournament (http://www.amd.com/ us-en/Processors/ProductInformation/ 0,,30_118_10220_9486%5E9621~75301,00 .html), Far Cry (http://www.amd.com /us-en/Processors/DevelopWithAMD/ 0,,30_2252_875_10543,00.html), and Shadow Ops: Red Mercury (http://www.amd.com/us-en/Processors/ ComputingSolutions/0,,30_288_11054_ 11705,00.html). (The 64-bit enhanced version of Shadow Ops is showcased at http://www.atari.com/shadowops/us/ amd.html.)

DDJ