Windows 7 Compatibility and Virtualization

In previous versions of Windows, applications could store files inside the \Program Files and \Windows folders, and they often took advantage of this to store common data that was shared among all users. The same was true for the Registry, a database of user and setup information— programs frequently stored information in the HKEY_LOCAL_MACHINE Registry section. To make Windows more secure, user programs are no longer allowed to store files or Registry data in these areas unless their setup programs explicitly change Registry security settings to permit it. (And this has to happen while the program is being installed under elevated privileges.)

Most of the applications that ship with Windows are subject to these restrictions. Try it yourself— open Notepad, type a few words, and try to save a file in \Program Files. You can’t. Any application that Windows deems as “modern” or “should know better” is entirely blocked from saving information in these protected areas. (Technically, the presence of a manifest file in the program’s folder or inside the program file itself is what tells Windows that the program is “modern.”) Older programs, however, expect to write in these privileged directories and Registry areas, and to maintain compatibility Windows 7 gives them an assist called file and Registry virtualization. What happens is that if an older program attempts to create a file in one of the protected folders or Registry areas and access is blocked, and the program is not running with elevated permissions and the file doesn’t have a manifest file, Windows stores the file or Registry data in an alternate, safer location. Whenever an older program tries to read a file or Registry data from a protected location, Windows first checks the alternate location to see whether it had been shunted there earlier and, if so, returns the data from that location. Thus, the application doesn’t actually store information in the secure locations but thinks it has. Why are we explaining this to you? There are two reasons:

• One consequence of virtualization is that programs that try to share data between users can’t. Each user will see only his or her private copy of the files that should have been stored in a common place. For example, in the “high score” list in a game, each user may see only his or her own name and scores. This may also cause problems with programs that track licensing or registration.

• If you go searching for files in Windows Explorer or the command- line prompt, you won’t see the files that got virtualized where you expected them to be because explorer.exe and cmd.exe have manifests—they don’t get the virtualization treatment, so they see only the files stored in their intended locations.

The first problem can’t be helped; the older programs just have to be redesigned and replaced. Knowing that virtualization occurs, you can work around the second problem by knowing where to look. Files intended for \Windows or \Program Files (or any of
their subfolders) will be placed into \Users\username\AppData\Local\VirtualStore\Windows or …\Program Files, respectively. Registry data intended for HKEY_LOCAL_MACHINE will be
shunted to HKEY_CURRENT_USER\Software\Classes\ VirtualStore\Machine. There is no quick-view button in the Registry editor, so to find this data, you have to browse to it.


If you view a folder in \Windows or \Program Files in Windows Explorer, a button named Compatibility Files appears in the window’s taskbar If you click this button, Explorer displays the corresponding subfolder in your VirtualStore folder. This is an easy way to examine your virtualized files.


Some Registry keys are not virtualized in any case. For example, most keys under HKEY_LOCAL_MACHINE\Software\Microsoft\Windows will not be virtualized; attempts to write data in this key or most of its subkeys will simply fail. This prevents rogue applications from creating startup program Run entries.

Source of Information : QUE Microsoft Windows in Depth (09-2009)