Tracking Virtualization

What Does "Legacy" Mean, Exactly?

Thus far, we've seen that Vista virtualizes when an application (1) tries to write to a protected area, (2) lacks the NTFS or Registry permissions to do so, and (3) is a legacy application. We've covered the first two conditions; now let's look at the third.

Vista will virtualize any application's read or write requests unless the application does one of several things.

• Runs with an administrator-level token. Vista assumes that if you're logged in as an administrator and are running a legacy application of some kind, then you must know what you're doing. In that case, Vista will allow the app to try to write to the file or Registry key. If the administrator lacks the permission to write to the file or Registry key, the operation will fail.

• Runs with a token that has write permissions to the file or Registry key. We've already covered this.

• Running in kernel mode. In the Windows world, programs either run as "user mode" or "kernel mode." Almost every program that you've ever installed on Windows runs in user mode: word processors, Web browsers, e-mail clients, games, spreadsheets, databases, and so on all run in user mode. The beauty of user mode is that each user mode application is placed in its own little "memory compartment" that it cannot write outside of. It is, then, impossible for a bug in a copy of Notepad to cause Notepad to overwrite some of the memory space allocated to, say, Calculator; when Notepad tries, it will trigger an error that will cause Windows to close down Notepad and ask you if Vista can send a trouble report to Microsoft about it. Kernel mode code, in contrast, can mess with whatever part of memory that it wants to, so buggy kernel mode programs can do a lot of damage. Basic operating system components, device drivers, and a lot of malware are three examples of commonly encountered kernel mode programs. (That's why one of the easiest ways to make your system unstable is to install a buggy driver. Or, I suppose, some malware!) The bottom line is that about the only kernel mode code you're ever going to be aware of installing is a device driver, and I can't see why a device driver would want to write to any of the protected locations. Virtualization would be fairly unnecessary for device drivers anyway, as they typically run with the token of the LocalSystem account, which has permissions to do just about anything anyway-it may be powerful, but it doesn't fall under Administrator Approval Mode. (If it did, you'd have to respond to about a thousand Consent UIs just to get a computer booted up!)

• Has a manifest with a level= parameter in it. If an application has a manifest, then Vista figures that it's been given the once-over, and doesn't need virtualization. (I should point out, however, that as of RC1 I found that the effect of manifests behaved differently for external manifests as opposed to embedded manifests when it comes to deciding whether or not to virtualize. That may be fixed by the time that you read this.)

• The user token is derived via impersonation. In the Windows world, "impersonation" essentially means that the application's token comes from a user logged on from across the network. In other words, in order for an application to enjoy the benefits of virtualization, then whoever's running that application must at least appear to be logged on locally rather than from across the network.

• The application is a 64-bit application. Virtualization is intended by Microsoft to be a mere bandage for temporary use. They reckon that any application built to be a 64-bit application is modern enough that its developer would understand what standard users can and can't do, and so would not need virtualization.

• The application seeks to modify a Registry key that has been marked "dont_virtualize." We've already covered this.

So long that an application does not meet any of these criteria, then it will get the benefits of file and Registry virtualization.