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.
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.
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
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.
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.
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.
If NTVDM.EXE is overall a 32-bit application… why couldn’t it be installed on x64 OS?. Indeed, we have DosBox if we want to run old DOS programs, and it works even better than the own NTVDM, but, what about those 16-bit apps for Windows? Installing virtual machines to then install another OS into is really a pain in the ass
Don’t you think it is time to let go of those “16-bit apps for Windows”? It’s 2014, after all.
That is a non-sequitur. Why should people have to stop using certain applications just because the current year is 2014 or 2015? And for many businesses, it is not financially viable to move their 16-bit programs to 32- or 64-bit ones.
There are a few solutions to run 16-bit Windows programs without NTVDM. One is to install a classic (non-NT) version of Windows in DOSBox. An easier alternative is to use Wine.