Windows x64 Part 5: NTVDM, Services, WoW64

This is the fifth part of a mini-series on Windows x64, focusing on behind the scene changes in the operating system. In the last article I explained that the 64-bit OS can only load 64-bit drivers. Today we will turn our attention to user-mode code and analyze how the move to x64 affects downlevel applications.

Virtual DOS

Remember DOS? That 16-bit OS from the days when a PC running at 4.77 MHz was considered state of the art? Long dead, you say? Unfortunately not. Every Windows NT-based OS up to and including Server 2008 has an emulation layer called “NT Virtual DOS Machine” (NTVDM.exe) built-in that is called upon whenever a 16-bit DOS program needs to be executed. Of course, running a program from the stone age of computing that thinks it owns the machine and can do dirty stuff like polling the keyboard controller in an infinite loop is problematic on a multitasking OS that does not allow any user-mode code to access the hardware directly, to put it mildly. Yet modern CPUs can still execute 16-bit code in 64-bit mode and thus support DOS apps on an x64 OS. However, Microsoft must have thought “enough is enough” and simply removed the virtual DOS machine NTVDM.exe from Windows x64.

That is great – on the one hand. The days of supporting DOS applications are finally numbered. Once every machine is on x64 DOS is finally dead. On the other hand, what if you need an old DOS app, maybe because there is no 32-bit version available or migration would be too costly? In that case, you simply would not migrate to x64, slowing the spread of Windows x64. In the long term, this will not matter. But if you intend to migrate to x64 soon, make sure you have only 32- or 64-bit apps.

Packing Windows

While 16-bit code has been banned from Windows x64, support for the prevalent 32-bit applications is, of course, required. This time Microsoft did not need to write a virtual machine, they built “Windows on Windows” instead, in short WoW64 (pronounced like “wow, this is 64!”). Whenever it is time for a thread of a 32-bit process to be executed, the processor needs to be switched from 64- to 32-bit mode. That is exactly what the WoW64 component Wow64cpu.dll does. WoW64 consists of two more DLLs: Wow64.dll, which translates calls from 32-bit apps into the 64-bit kernel and implements file system and registry redirection (to be discussed later), and Wow64win.dll, which intercepts and translates calls to the Win32 subsystem’s kernel-mode component Win32k.sys.

The net result of having WoW64 is that 32-bit programs run flawlessly on Windows x64. They only load the three WoW64 DLLs which take care of compatibility issues. Apart from that, a 32-bit process looks just like a 64-bit process. Even in task manager. That is why “*32” is being added to each 32-bit process’ name: to provide an easy means of identifying which component is (still) 32-bit.

Overhead

Whenever a process accesses a disk, the network, the registry, or any other system resource, the corresponding API call invariably ends in kernel mode. The x64 kernel, of course, expects 64-bit data structures (pointers and the like). 32-bit applications, on the other hand, use 32-bit data structures. Thus conversion (called thunking) is required, which is performed by the WoW DLLs mentioned above, but it comes at a price. Not so much performance – CPU overhead is negligible in most cases – but RAM. Converting 32-bit data to 64-bits essentially doubles the amount of RAM required to store the data. However, since only some data structures need to be converted and the use of those structures varies greatly between applications, it is simply not possible to give a good estimate of how much more RAM is needed to run a 32-bit app on x64 than on x86. As often, it depends…

Only one thing is certain: not only do you need more RAM to get the same performance with 64-bit programs on x64 as compared to 32-bit programs on x86, but the same is also true for 32-bit apps on x64. Simply put, when you move from 32- to 64-bit Windows, you will need more RAM to get the same performance as before, regardless of whether your apps were compiled as 32- or 64-bit.

Services

Windows x64 can only load 64-bit drivers. Bad enough. But what about services? Here comes the good news. Services run in user mode and are thus unaffected of the 64-bit driver doctrine. 32-bit system services work perfectly well on Windows x64.

This concludes today’s article. In the next posts I will try to fulfill my promises and dive in deeper into those intricate little details by which Windows x64 differs from its x86 twin.