When I first started digging into the final implementation of UAC one of the things I did not realize was how tightly coupled UAC and application compatibility are. Call it a "well duh!!" moment. A significant part of that relationship revolves around virtualization of parts of the system registry and certain system directories. File and registry virtualization as implemented in Vista is technology that enables older programs to work without change and without damaging the system. Note that this is not a long term solution for these programs. There is a minor performance hit and running a mix of virtualized and non-virtualized programs can cause problems if the different programs are attempting to work with each other. As well, different users on a machine might not be able to share data. More on that in a bit. In the long term Microsoft does not plan on supporting virtualization as a solution for older programs. This is intended as a stop gap solution to allow developers the time to fix their programs. Exactly when Microsoft will draw the line in the sand hasn't been announced.
Update: There is a lot of published documentation from Microsoft that states virtualization is disabled for 64b processes in Vista 64. When I have the time I'll verify this, but it appears that virtualization for 64b applications does in fact exist within Vista 64.
First, why registry and file virtualization? Way back at the beginning of Windows, application developers had unrestricted access to the system. They could do things that would cause stability issues and system crashes. They could also damage and crash other programs. Crapware authors take advantage of this in order to hook themselves rather deeply in to the system. Sometimes to the point of being able to hide themselves from view of most, if not all, system tools. But, keeping crapware off the system is not the main purpose of UAC. UAC does help with fending off crapware, but at best all it can do is help reduce the impact of crapware infection on the system as a whole. UAC will not prevent crapware from infecting the user's personal environment and UAC does not address social engineering. Setting aside what crapware authors do, there are a lot of perfectly legitimate programs that do less than wise things in terms of where they store user, rather than system wide, data. Part of the reason why this is the case is simple ignorance. Even Microsoft did less than wise things, in this regard, in the early days. The primary reason for UAC and virtualization is to allow legitimate applications to run while preventing them from destabilizing the system and other applications. The impact on crapware is only of secondary concern, but profound never the less.
So what is virtualization? In this context it means that when a program running without administrator rights attempts to write to certain areas of the registry or directory structure, those writes will be redirected to user specific and private areas of the registry and disk. If the program then reads data from these areas, it will see user specific values, rather than system global values. It is because virtualization redirects writes and reads to user specific areas that sharing data between users on the machine becomes a challenge.
For demonstration purposes I'm going to use command prompt to show what happens with virtualized directory structures.
First launch a command prompt in default mode. Assuming you haven't disabled UAC, click on start and in the search box type in "cmd" and hit enter. Next, hit ctrl-shift-esc to launch task manager. Once task manager has launched switch to the process tab, hit view, then select columns. At the minimum scroll all the way down and the "Virtualization" option as shown:
Check the option to display virtualization status then hit [OK]. Notice that virtualization for the command prompt, cmd.exe is disabled. Also note that the shell, explorer.exe has virtualization disabled.
Now start an elevated command prompt by right clicking a short cut to command prompt and selecting "Run as administrator". Once that prompt is running, take a peek in task manager. Notice that virtualization is not available.
Now the fun begins. In the standard mode command prompt enter "cd %windir%\system32" and hit enter to change to the system32 directory. This takes you to a protected part of the directory structure. Standard users can not write in this area. To prove that point, type in "md test" and hit enter. Notice that you get an "Access is denied" message.
Shift to the command prompt in administrator mode and repeat the make directory command then change to the new "test" directory in both command prompts.
Now that we have a "safe" area in a protected part of the system area, let's really see what virtualization does in action. First, let's create a failure. In the standard mode command prompt, type in "dir >dir.txt". Again note that it still gets "Access denied".
Now, switch back to task manager. I'm going to combine a couple of screen shots for this next step. Right click the standard mode command prompt. You'll see and option called virtualization. Click on that to turn virtualization on and you'll get a task manager warning dialog. Click [yes] to allow the change.
Now if you look in the virtualization column you'll now see the new status. Minimize task manager to get it out of way and switch to the standard command prompt. Rerun the directory command above, then run the dir command to actually display the contents of the directory on the screen. Notice that it now appears the standard user is writing to protected parts of the system.
Or did it really write data to a protected part of the system? Switch to the Administrator level command prompt and enter a dir command.
This is where the data really went:
Registry virtualization occurs in a similar way however the virtualized data is stored in the registry. Virtualization is limited to HKLM\Software. When a program running in standard mode, with virtualization enabled, attempts to write anywhere in HKLM\Software, the write is redirected to HKCU\Software\Classes\VirtualStore.