File and Registry Virtualization Considerations

I've previously mentioned nonadministrative applications-so-called productivity applications and games, mostly-that require elevation to run despite the fact that they aren't intended to do anything administrative. Part of the reason why something like a personal accounting program or a technical drawing program or an e-mail client (to name three that come to mind offhand) would require elevation is because those applications are, to put it baldly, defectively built. Some write user configuration data into HKEY_LOCAL_MACHINE rather than HKEY_CURRENT_USER. Others install their applications to Program Files, which is perfectly fine, but then store user-created data files right in the same directory as their programs, in Program Files, which is quite bad, as the NTFS permissions for Program Files don't let users write files. It's frustrating to see third-party independent software vendors produce this kind of software, but they're not the only culprits by any means-one of the worst offenders here has been Microsoft itself, although they say that's changing. Nevertheless, Visual Studio Express puts projects in its Program Files directory by default, and SQL Server 2000 and 2005 both put databases in their Program Files directories as well. Arrgh.

I've mentioned System32 and Program Files, but they are not the only verboten areas in the file system. XP changed things by disallowing the Everyone group from creating files in the root directory of a computer; Vista continues that trend.

Note 

In fact, Vista locks down the Windows directories so much that it's a major job to enable an administrator to change anything in those directories, but that's a story for the next chapter.

File and Registry Virtualization Basics

What does all of this mean? Well, essentially, the fact is that some of the most basic, simplest programs in the world may stop working under Vista. Of course, Microsoft knows full well that if Vista were to break a lot of applications, then folks might decide not to use Vista. So they added an interesting fix that catches the bad behavior of some applications and amends that behavior on the fly. They call that fix "file and Registry virtualization."

In short, here's how file and Registry virtualization works. When an unelevated application tries to write to one of three folder locations-Program Files, Program Files (x86), and \Windows-then that file write is automatically redirected to a folder in the user's profile, and, best of all, the application has no idea that it's happened. A similar thing happens whenever an application tries to write to the HKEY_LOCAL_MACHINE\SOFTWARE key in the Registry, as any such writes get automatically redirected to another key in HKEY_CURRENT_USER. The old application has no idea that it hasn't written to some protected folder or Registry key, so it's happy, and the data's not in a protected system area, so those of us wanting to keep standard users from writing data to those areas are happy.

Hmmm…that sounded good for a write operation, but what about a read? When the application goes to read the data that it thinks it wrote into, say, C:\Windows, then what happens? Clearly the data file isn't in C:\Windows, it's in some alternate location, so won't the read attempt fail? No, fortunately. When a pre-Vista application tries to read from a protected location, then Vista quietly first checks the place that it stashes virtualized data and, if it finds the file that the application's looking for, then it delivers it, saying "here it was in C:\Windows, just like you told me." If the file isn't in the virtualized data area, then Vista looks in the protected location to see if the file is in the protected location and, again, the application is blissfully unaware of all of this. As far as it's concerned, it asked for the file or Registry entry, and it got it.