Windows x64 Part 7: File System & Registry Redirection, Registry Reflection
This is the seventh 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 mixed 32-/64-bit processes are not allowed and how that rule affects both administrators and script-writers. In this context I mentioned the strangely named directory
SysWOW64. Today I am going to explain what it is used for by starting with redirection.
As you know, every Windows installation has a directory
System32 that contains most DLLs that ship with the operating system. The names of many of those DLLs are well-known.
ntdll.dll, for example, are used by almost every application. Some DLLs contain the number 32 in their name, some do not. That, however, is misleading: all DLLs in
System32 of a 32-bit system are 32-bit images. Programmers know and expect this. When they need a certain DLL they have their program load the appropriate DLL from
System32 and all is well.
Consider a programmer who wants to make his product available both as 32- and 64-bit versions. He will do that by defining two compiler configurations, one for 32 bit, one for 64 bit. Without changing a single line of code he can build both a 32-bit and a 64-bit version of his application (provided he wrote good code in the first place). Wait. There must be a catch somewhere.
There is. The path to the
System32 directory will (more often than not) be hard-coded in the program. We now have a 32- and a 64-bit application that both expect system DLLs to reside in the
System32 directory. Both can run on the same (x64) system. Both can only load and use DLLs that have the same bitness as themselves. 32- and 64-bit DLLs have the same names.
Not quite. Actually the solution is quite simple: use two
System32 directories, each containing either 32- or 64-bit DLLs, and show each process the folder appropriate to its bitness under the name
System32. That is, in a nutshell, what the file system redirector does.
In reality, it is a little more difficult, as you probably have guessed. Windows x64 has a directory
System32 that contains 64-bit DLLs (sic!). Thus native processes with a bitness of 64 find “their” DLLs where they expect them: in the
System32 folder. A second directory,
SysWOW64, contains the 32-bit DLLs. The file system redirector does the magic of hiding the real
System32 directory for 32-bit processes and showing
SysWOW64 under the name of
To make things more interesting, redirection is disabled for several subfolders that contain data independent of an application’s bitness (log files and the such):
Additionally, 32-bit processes “see” a different program directory.
%ProgramFiles% points not to
C:\Program Files but to
C:\Program Files (x86).
Of course, loading DLLs directly from a file system path is only one of several prevalent techniques. Another involves the registry which stores registration information of COM servers (DLLs, often, EXE files, sometimes). Windows x64 needs to ensure that 32-bit processes only “see” DLLs they can actually load (the same applies to 64-bit processes, obviously).
On Windows x64, several high-level registry keys containing information specific to the bitness of a process have a sub-key called
WOW6432Node. 64-bit applications see all of the registry while 32-bit processes get to see the contents of the
WOW6432Node subkey instead. To be specific:
HKLM\Software -> HKLM\Software\WOW6432Node
HKCU\Software\Classes -> HKCU\Software\Classes\WOW6432Node
As with the file system, there are exceptions. Many registry keys containing data independent of a process’s bitness are excluded from the redirection. The following keys exist only once on Windows x64:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Time Zones
We know now that 32-bit processes see different content in several parts of the registry than 64-bit processes. Yet, in the attempt to isolate 32-bit from 64-bit DLL registration information, the registry redirector goes too far. The key
HKLM\Software\Classes, for example, contains not only information on DLLs, but also file type associations (and other data). Who would want to associate the file extension DOC with Microsoft Word in 64-bit Explorer and end up in Wordpad when double-clicking a DOC file in a 32-bit instance of Windows Explorer?
To prevent that from happening, another component, called registry reflection, copies select data between the 32- and 64-bit views of the registry. Reflection is enabled for:
There are several things to note:
- The reflection mechanism has some built-in logic: only registration information on out of process COM servers is reflected (out of process COM servers are executed in their own process, not in the process of the caller – in essence, EXEs, not DLLs).
- The “last writer wins” principle applies. If you install IrfanView 32 bit and then Photoshop 64 bit (whenever that will be available), most image file types will probably be associated with Photoshop.
- No (64-bit) program should create registry keys called “WOW6432Node” or (64-bit) programs recursively enumerating registry keys might end up in endless loops.
Microsoft has put a great deal of thought and work into the redirection and reflection processes to make the transition to Windows x64 as seamless as possible. These processes, however, have side-effects. One of them being that 32- and 64-bit applications do not “see” the same COM servers.
With this note, I officially conclude this series. I might (and probably will) post additional articles detailing specific aspects of the x64 platform. The same applies to my colleague Nicholas Dille.