Seeing Virtualization in Standard Versus Administrative Users

Which Areas Are Protected and Where They Are Virtualized

I've been writing "file and Registry virtualization" all in one breath as if it were one uniform operation but, as you'll see, it isn't-they're two somewhat different animals. File virtualization has a lot fewer details about it than does Registry virtualization, so we'll start there.

How Virtualization Handles Files

File virtualization protects just two folders on the x86 version of Vista, and three folders on the x64 version:

• \Windows and its subfolders

• \Program Files and its subfolders

• \Program Files (x86) and its subfolders

As before, "Program Files (x86)" only appears on systems running the 64-bit versions of Vista. (Note that's 64-bit Vista, not just a 64-bit chip: you can run any of the 32-bit versions of Vista on a computer equipped with a 64-bit chip, and they'll run just fine. But you won't see the "Program Files (x86)" folder on your system.)

Notice that the list of folders that file virtualization protects almost exactly matches the list of "secure locations" that User Account Control refers to in the "User Account Control: Only elevate UIAccess applications that are installed in secure locations," but the match isn't perfect; for some reason, that group policy setting considers only \Windows\System32 secure, where in comparison file virtualization protects all of \Windows.

File Writes under Virtualization

Any time a virtualized application tries to write to one of those two or three folders, file virtualization redirects those writes to an area in a user's profile, \Users\ username \AppData\Local\ VirtualStore. Thus, if I were logged into my system with a username of "Mark," then my redirected files would all end up in \Users\Mark\AppData\Local\VirtualStore. Within Virtual-Store, file virtualization creates folders whose names correspond to the folders that the legacy application was trying to write into-Windows, Program Files, or whatever. So, for example, if some legacy application tried to write a file named appsettings.ini to \Windows\System32 on my computer, then appsettings.ini would actually end up in \Users\Mark\AppData\Local\ VirtualStore\Windows\Settings\appsettings.ini; take a look back at the exercise that we did earlier in this chapter and you'll see that Vista behaved as expected there.

Note 

Of course, if for some reason the virtualized application's token actually has the permissions to write to the protected location, then file virtualization stays out of the way and lets the application actually write to the protected location.

File Reads under Virtualization

When a "virtualized" application tries to read a file from one of the protected locations, then Vista assumes that the same application tried to write to that location and was redirected. That's why legacy file read attempts cause Vista to always look in the VirtualStore folders before checking the actual locations. So, for example, if a user named Mary were to run a legacy application that asked Vista to open a file named \windows\system32\appsettings.ini, then Vista would first look for a file with the file specification \Users\Mary\AppData\Local\ VirtualStore\Windows\System32\appsettings.ini and, if that file exists, then Vista would deliver that to the application. If Vista doesn't find a file with that specification, then it checks to see if \Windows\System32\appsettings.ini exists and, if it does, then Vista gives that to the application.

Notice that the fact that Vista's rule for locating files means that Vista doesn't have to have any kind of "memory" about what files it has stuffed into VirtualStore in order to locate them when it needs to read them. Its "how to write files" rule just says "if it's a virtualized application making the request, and the requested location is protected, then actually write the file in VirtualStore," and its "how to read files" rule says "if it's a virtualized application making the request, and the requested location is protected, then first look for the file in VirtualStore and, if it's not there, then look in the protected location."

Note 

Can you change the list of protected folders from the two or three that Vista ships with? No, unfortunately not. Microsoft sees file and Registry virtualization as something that's a short-term bridge that people can use to continue to use legacy apps for just a little while longer before getting up-to-date applications, and doesn't want to encourage people to become dependent on it. Making it more flexible would do that, I guess.

How Virtualization Handles the Registry

Vista virtualizes the Registry as well, but only the HKEY_LOCAL_MACHINE\SOFTWARE key. Its basic approach is the same:

• If a legacy application without the proper Registry permissions tries to write to a location anywhere in the HKEY_LOCAL_MACHINE\SOFTWARE key, then Registry virtualization writes the data instead to an alternate location and tells the application that the write operation succeeded.

• If a legacy application tries to read anywhere in HKEY_LOCAL_MACHINE\SOFTWARE key, then Vista first looks in the alternate Registry location for that data. If it finds the data that it's been sent to get, then Vista returns the data from the alternate location. If the data isn't in the alternate location, then Vista looks in the originally requested location and, if it finds it, gives that data to the application successfully.

Registry virtualization is, however, a bit different in a few ways. First, the alternate location clearly isn't a folder in the user's profile. Instead, it's a new key, HKEY_CURRENT_USER\Software\ Classes\VirtualStore\MACHINE\SOFTWARE. So, for example, if an application tried to create a new key HKEY_LOCAL_MACHINE\SOFTWARE\Mynewkey, that key would actually end up as HKEY_ CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE\Mynewkey.

You can try this out with another of my homemade legacy applications, which you can download at http://www.minasi.com/vista/regwritekey.exe. Save the file, as before, in c:\mystuff. Then open a command prompt, navigate to c:\mystuff, type regwritekey, and press Enter. That application tries to create a new Registry key named HKEY_LOCAL_ MACHINE\SOFTWARE\Testkey. To see what it really did, start up Regedit and look in HKEY_LOCAL_MACHINE\SOFTWARE; you won't see a Testkey folder. But now open up HKEY_ CURRENT_USER\Software\Classes\VirtualStore\MACHINE\SOFTWARE and you'll see a key Testkey, as you see in Figure 3.1.

Figure 3.1: The virtualized Testkey folder

As with file virtualization, you can't extend the range of Registry keys protected but, unlike file virtualization, you can fine-tune which keys are protected by virtualization. For any given Registry key in HKLM\Software, you can specify whether or not Vista should virtualize for that key. You do it with the reg.exe application that you may recognize from earlier Windows versions, but in Vista it gets a new parameter, "flags." You can tell Vista not to virtualize a key like this:

 reg keylocation dont_virtualize [/s] 

Where the optional /s means "make this change to this key and its subkeys as well." For example, to tell Vista not to virtualize the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft key and its subkeys, type (from an elevated prompt):

 reg hkey_local_machine\software\microsoft\ dont_virtualize /s 

That's all one line, even if it broke on the printed page. It's important to understand that "Don't virtualize" doesn't mean "let the low-privilege legacy application modify this key"; it just means "ignore the application's attempt to modify this key."