Professor Windows - August 2001
By Zubair Ahmad
32-bit Operating systems, such as Windows NT and Windows 2000, support up to 4 gigabytes (GB) of memory. Over the years, 32-bit Windows applications have not only grown in size, the need for applications to have the ability to manipulate large amount of data have dramatically increased. Today million of users around the world need to access terabytes of data in real time and the demand for an advanced, scalable architecture that can support a large amount of memory is understandable. The obvious question is: should you be considering a move to 64-bit Windows? In this column, we will explore the answer to this question. We will discuss the advantages of 64-bit Windows over 32-bit, talk about a few concepts and give you some tips on how you can prepare for the next wave of Windows. We will also examine some limitations of 64-bit Windows, including the reasons that 64-bit processes cannot load 32-bit DLLs. We will address the fate of 16-bit and 32-bit applications in a 64-bit environment. Finally, we will talk about some general guidelines for porting 32-bit applications to 64-bit.
Why 64-bit Windows?
In keeping with the business demand for a highly scalable, advanced, 64-bit platform that supports a large memory footprint, Microsoft is developing the next generation of Windows, which is based on Intel's 64-bit chip. The IA-64 systems with their advanced floating point arithmetic extensions, and powerful multiprocessing features will compliment Microsoft's 64-bit Windows platform to meet the demands of today's high-end businesses. Organizations dealing in online data processing, large scale data warehousing, e-commerce, high-end graphics and multimedia, will appreciate the benefits of moving to a 64-bit platform.
Microsoft has designed Windows XP 64-bit Edition to support 16 GB of RAM and eight terabytes (TB) of virtual memory. With this level of support, organizations will be able to use a single desktop for high-end technical applications as well as the standard business applications. In addition, most 32-bit Windows applications will operate seamlessly in a Windows on Windows 64 (WOW64) subsystem on Windows XP 64-bit Edition.
Advantages of 64-bit Windows
Compared to the 4GB of physical memory that 32-bit Windows supports, a 64-bit operating system can support up to 16 GB of memory, as mentioned above. The increased memory has several benefits. Larger amount of RAM means we can run more applications in physical memory and avoid paging to the slower hard disks. We can also support larger number of users and the performance is enhanced because applications can store larger amount of data in memory, which results in improved data access. The end result will be that you will lower your total cost of ownership not only because you can save on hardware costs (fewer servers), but you will also save time and money in management overhead.
Developers of games will be able to take advantage of 64-bit performance boost by reducing the time spent in digitally rendering three-dimensional models. From the aerospace engineers to the automobile manufacturers, the CAD/CAM engineers to 3D animators, 64-bit architecture will be beneficial in improving calculation speeds and providing a large memory set for mission-critical applications.
Microsoft's goal for 64-bit Windows is to ensure compatibility with Windows 2000-based and other existing 32-bit applications. Developers will be able to use a single source code base for 32- and 64-bit applications. The Microsoft Platform Software Development Kit(SDK) includes several features that make it easier for you to write applications for dual platforms (32- and 64-bit Windows). The Platform SDK also includes a 64-bit toolkit that contains a 64-bit MIDL compiler (Midl.exe). The compiler can be used to generate native 64-bit stubs, as well as 32-bit stubs. By default, dual stubs are generated that run on both platforms. If you only want to generate 64-bit stubs then use the /env win64 switch.
The following table offers a comparison of 32- and 64-bit architecture.
Comparison of 64-bit and 32-bit Architectures
|Architectural Component ||64-bit Windows 2000 ||32-bit Windows 2000 |
|Virtual Memory ||16 TB ||4 GB |
|Paging file size ||512 TB ||16 TB |
|Hyperspace ||8 GB ||4 MB |
|Paged pool ||128 GB ||470 MB |
|Non-paged pool ||128 GB ||256 MB |
|System cache ||1 TB ||1 GB |
|System PTE ||128 GB ||660 MB |
Preparing for 64-bit Windows
To run Win-32 based applications on 64-bit Windows you use an emulation layer. When dealing with 64-bit Windows, even though a 32-bit process can't load a 64-bit DLL and a 64-bit process can't load a 32-bit DLL, the support for remote procedure call (RPC) on 64-bit Windows allows communication between 64-bit and 32-bit processes. This support exists for communications on the same computer as well as across other computers. Another thing to keep in mind when dealing with process interoperability is that on 64-bit Windows an out-of-process 64-bit COM server can talk to a 32-bit client and an out-of-process 64-bit COM server can communicate with a 32-bit client. Why is this important? Because if you have a 32-bit DLL that is not COM-aware, you can simply wrap it in an out-of-process COM server and use COM to make calls to and from a 64-bit process.
I mentioned earlier that 32-bit processes can't load 64-bit DLLs and 64-bit processes can't load 32-bit DLLs. You might be wondering why? Well, one of the reasons has to do with "thunking". By default, 64-bit applications can use 8 TB of user mode address space. You have the option to specify that all memory below 2 GB be allocated to the application. Because 32-bit DLL can't address memory space above 2GB, the thunk layer would have to copy all data into the low 2GB of the 64-bit application. Obviously, this won't work if the 64-bit application tries to pass a pointer to data that is larger than 2GB.
32-bit DLLs use x86 style exception handling and 4K pages. On an IA-64 processor, the native page size is 8K and the WOW64 emulator is responsible for simulating 4K pages. Because on an x86 machine exceptions do not "unwind" from user mode to kernel mode and back, WOW64 implements x86-style exception without switching from x86 code to IA-64 and back.
Finally, another reason why 64-bit and 32-bit processes can't load each other's DLLs is that system DLLs (kernel32.dll, user32.dll, and gdi32.dll) expect only one instance per process, 32-bit or 64-bit. If a process contained more than one instance of, say user32.dll, Win32k.sys will not be able to distinguish between them and wouldn't know which one to call.
16- and 32-bit Applications
As far as 16-bit Windows-based applications are concerned, 64-bit Windows does not support them. If you try to run a 16-bit application in 64-bit Windows you will get an ERROR_BAD_EXE_FORMAT error. Because handles have 32 significant bits in 64-bit Windows, you can't pass them to 16-bit Windows without losing data.
Win32-based applications can run seamlessly on 64-bit Windows with the help of x86 emulator known as WOW64. The system totally isolates 32- and 64-bit applications so there are no file or registry collisions between them. Users can cut and paste between the two transparently. However, we should make one thing clear. The purpose of WOW64 is to provide seamless interoperability between the 32- and 64-bit boundaries by allowing us to run 32-bit applications in 64-bit Windows. It is not meant to run 32-bit server applications.
Guidelines for Porting 32-bit Applications to 64-bit
If you have ported 16-bit applications to 32-bit in the past then you will be glad to know that porting 32-bit applications to 64-bit is much easier. Microsoft offers several planning tips to ensure that your transition from 32-bit to 64-bit will go smoothly. Check out Getting Ready for 64-bit Windowson Microsoft's Web site.
If you work for a large organization you may have several teams of developers working on portion of the code. You should communicate with them to make sure that they are also working on the 64-bit code.
As mentioned earlier, you can't run 16-bit legacy Windows applications on 64-bit Windows. Obviously, you'll have to rewrite those applications. The advance architecture of IA-64 processor, with its superior floating point capabilities and support for a large amount of RAM will be a good enough reason for you to rewrite x86 assembly code as well even though you could run that code in WOW64.
When you compile your 32-bit code with a 64-bit compiler, you may experience warnings and errors. You should document the problem areas and share them with all the teams that could possibly be affected. Although possible, it is not recommended that you port only portions of your 32-bit code to 64-bit. Test your code thoroughly and avoid cutting corners to gain temporary benefits.
You should decide whether you plan to use 32-bit test tools or 64-bit. Most developers will settle for a combination of the two. Test your 32- and 64-bit COM and RPC components to make sure they are communicating properly. To test the 32-bit components, first recompile the code to 64-bit. Run the code and fix any problems that exist. Then recompile in 32-bits and test again. Finally, recompile to 64-bit and test your code again.
During testing, experiment with various amounts of RAM on the server. You may discover some unexpected behavior in either the application you wrote or the operating system itself. It is best to cover as many areas as you can and be thorough.
Windows XP 64-bit Edition and Intel's Itanium processor are a combination that developers are anxiously waiting for. Imagine the benefits that Servers, such as Exchange Server 2000, can reap from support for large amounts of physical memory and addressable space. 64-bit Windows is right around the corner. It will take not only data processing and powerful multiprocessing but also the application development to the next level. What's next? Well, let's keep our fingers crossed and for now concentrate on moving to 64-bit Windows.
For any questions or feedback regarding the content of this column, please write to Microsoft TechNet at email@example.com.