Registry Reflection in Windows 7 and Server 2008 R2 x64? Gone for Good!
Although the architecture of Windows x64 is still relatively young, Microsoft already changes it in Windows 7 by removing registry reflection. Just in case you wonder what I might be talking about: read up on 64-bit Windows in my detailed 7-part series whose last article explains registry reflection.
Recap on Registry Redirection and Reflection
Before Windows 7, the area of the registry that contains information on COM servers and file type associations was separated between 32-bit and 64-bit processes. The separation mechanism is called registry redirection. This had the benefit of 32-bit processes only seeing 32-bit COM servers and 64-bit processes only seeing 64-bit COM servers. Unfortunately the registry area in question, mainly HKEY_LOCAL_MACHINE\Software\Classes, also stores file type associations. In order to prevent 64-bit processes from opening DOC files in another program than 32-bit processes, a component called registry reflection copied certain information between the two views of the registry.
This seems to have caused inconsistencies, at least in certain scenarios I assume.
Windows 7 and Server 2008 R2 neither redirect nor reflect those parts of the registry where COM registration information and file type associations are stored. As with, say, the group policy registry key, only one version exists that is seen from 32-bit and 64-bit processes. This change affects the following keys:
HKEY_LOCAL_MACHINE\Software\Classes HKEY_LOCAL_MACHINE\Software\Microsoft\COM3 HKEY_LOCAL_MACHINE\Software\Microsoft\EventSystem HKEY_LOCAL_MACHINE\Software\Microsoft\Ole HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc HKEY_CURRENT_USER\Software\Classes
According to the MSDN article announcing the removal of registry reflection, discarding it is possible because the only “known” consumer of reflection was COM. By updating COM to not require reflection any more, the copying mechanism called reflection can be done away with.
The reflector was not just a dumb copy job, though. It made sure to only copy registration information of out of process COM servers, i.e. EXEs, to guarantee that 32-bit processes never try to load 64-bit DLLs (which is impossible) and vice versa. In order to separate bitness-specific COM registration information on Windows 7 and Server 2008 R2, the following subkeys of the classes hive are now redirected:
HKEY_LOCAL_MACHINE\Software\Classes\AppID HKEY_LOCAL_MACHINE\Software\Classes\CLSID HKEY_LOCAL_MACHINE\Software\Classes\DirectShow HKEY_LOCAL_MACHINE\Software\Classes\Interface HKEY_LOCAL_MACHINE\Software\Classes\Media Type HKEY_LOCAL_MACHINE\Software\Classes\MediaFoundation
Note: I got above list from an installation of Windows 7 beta 1. The cited MSDN article only mentions the keys “CLSID” and “Interface”.
Pros and Cons
Having to deal with two views on the same data is bad enough. Not having to deal with a component copying a subset to and fro any more is certainly an improvement, all the more since the copying certainly did not make the system run faster. So on the upside, we have reduced complexity and potentially less overhead meaning slightly higher performance.
On the downside, there might be compatibility. What about applications that use the API functions RegQueryReflectionKey, RegEnableReflectionKey and RegDisableReflectionKey? At least in the beta 1, there seems to be the problem that those functions are exported (i.e. should be present) but are not implemented.