When a 32-bit application is run on top of an x64 version of Windows, the WOW64 emulator redirects the Program Files folder and calls to DLL files. But these aren't the only things that are redirected. The WOW64 emulator also redirects certain portions of the Windows registry. This article will show you how registry redirection works.
The Windows registry is a file that contains the majority of the configuration data for the Windows operating system. The registry contains a huge variety of settings, but the configuration data that the WOW64 emulator is most interested in is a list of all of the Component Object Model (COM) objects that have been registered by the operating system.
COM provides a way for applications (.exe files) and libraries (.DLL files) to make themselves accessible to any COM-compliant application or script. COM makes it possible for someone with minimal programming skills to write an application or script that interacts with Windows. The person writing the application or script can do so without having to learn a programming language such as C++, and without having to learn all of the Windows application programming interfaces (APIs).
Windows is designed so that all available COM objects are listed within the registry. Keep in mind, though, that 32-bit code must remain completely isolated from 64-bit code. As such, 32-bit and 64-bit COM objects are stored in two different parts of the registry.
Before I show you how and where these COM objects are registered, you need to understand the difference between in-process and out-of-process servers. In Microsoft speak, a COM server is an object that makes its functionality available through COM. In contrast, the applications or scripts that make use of that functionality are called COM clients.
An in-process server usually refers to libraries (DLL files). Libraries are called in-process servers because they execute as a part of the same process as the application or script that called them. An out-of-process server is a COM object (usually an executable file) that runs in a different process than the application or script that called it.
Now that you've had a crash course in COM, let's talk about registry redirection. When an application attempts to register a COM object, the WOW64 emulator will place the registration in the appropriate section of the registry, depending on whether the COM object is a 64-bit or 32-bit object.
When an application or a script tries to load a COM object in process, the WOW64 emulator uses registry redirection to make sure that the application or script reads the portion of the registry that refers to 32-bit COM objects. If the registry does not contain a reference to a 32-bit version of the requested COM object, WOW64 will tell the application that the object doesn't exist, even if there is a 64-bit version available. The same thing happens if a 64-bit application requests a COM object. Windows will check the 64-bit portion of the registry for a reference to the object and will ignore any 32-bit COM objects.
The way that WOW64 redirects in-process server requests is fairly straightforward. But things work differently for out-of-process servers. Registry redirection is still required, but that is only part of the process.
Throughout this series of articles, I have repeatedly stressed the importance of keeping 32-bit and 64-bit code isolated from each other. Out-of-process server calls is the exception to the rule.
Isolating 32-bit code is normally a requirement because you can't mix 64-bit and 32-bit code within a process. But when it comes to out-of-process servers, the COM object is running in a completely different process from the code that called it. This means that the application can be running 32-bit code and call a 64-bit COM object, or vice versa.
Since the application and the COM object are running in different processes, it's easy to see how it would be possible to run them both on the same system. But how can the application communicate with a COM object if one is running 32-bit code and one is running 64-bit code? Although the application and the COM object can't interact directly with each other because they are running in different processes, they can communicate through Remote Procedure Calls (RPCs).
Computers running an x64 version of Windows use registry redirection to accommodate running 32-bit and 64-bit applications. This registry redirection prevents 32-bit applications from overwriting 64-bit registry settings, while still allowing applications and DLL files with hard-coded registry paths to continue to function.
Registry keys related to applications are usually installed in the HKEY_LOCAL_MACHINE\Software hive of the registry. In an x64 version of Windows, this hive is used exclusively for storing configuration data related to 64-bit applications. Configuration data related to 32-bit applications is stored in the HKEY_LOCAL_MACHINE\Software\WOW6432node registry hive.
Obviously, 32-bit applications are not designed to look in the HKEY_LOCAL_MACHINE\Software\WOW6432node registry hive. The WOW64 emulator intercepts registry calls from the 32-bit applications, and transparently redirects those calls to the appropriate location within the Windows registry.
Admins familiar with the Windows registry know that the HKEY_LOCAL_MACHINE\Software hive often contains more than just configuration data for applications. Sometimes this hive stores configuration data related to things such as object linking and embedding or remote procedure calls. Therefore, calls to the following sub keys are also redirected:
On the surface, registry redirection looks fairly simple. Even so, some Windows functions that you take for granted, such as object linking and embedding and file extension associations, would not function correctly if simple redirection were the only mechanism used. Therefore, x64 versions of Windows also rely on another technique known as registry reflection. My next article will discuss registry reflection.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. He writes regularly for SearchWinComputing.com and other TechTarget sites.
More information on this topic: