How SVS works with Classes in the Windows Registry
Randy Cook gives us some vital info about how SVS interacts with the Windows Registry. If you're faced with editing the registry of a virtualized app (shudder) this tip could be a life saver.
If you come to a point in life when you need to tweak the Registry of a virtualized application, you'll want to keep this explanation of how SVS works with registry keys within reach.
The HKEY_CLASSES_ROOT key is a virtual key that Windows creates by combining the data from HKEY_CURRENT_USER\Software\Classes and HKEY_LOCAL_MACHINE\Software\Classes. When there is a conflict in this data, preference is given to the data contained in HKEY_CURRENT_USER\Software\Classes.
SVS does not store data in the virtual HKEY_CLASSES_ROOT key. Instead it stores it in its real location under either HKEY_CURRENT_USER\Software\Classes or HKEY_LOCAL_MACHINE\Software\Classes. At runtime, Windows reads the SVS data for active layers from these locations and properly renders HKEY_CLASSES_ROOT.
Editing registry keys of a virtualized application is a bit different than editing normal registry keys. Here's how to get started:
Make sure the application you want to work in is deactivated. Here's how to use the Trinket utility to deactivate version 5 of the Acrobat Reader.