Leave the Laptop Behind

Fun in the Sand

It all begins in the sandbox. Incorporating concepts pioneered years ago by distributed computing enthusiasts, application virtualization uses sandboxing to isolate changes made by a running application and redirect them to a specific, reserved area of the local file system.

The first step is capturing the application's installation procedure. Often referred to as "sequencing," the process typically involves some form of wrapper utility that invokes a virtualization layer (usually a file system redirector with some additional monitoring components) and then prompts you to execute the application's installer. As the installation proceeds, the sequencing utility records the changes it makes to the system and builds a virtual map of what needs to go where -- in the file system and Registry -- in order for the application to execute. This map is then used to splice in the now virtualized application components at runtime to create the illusion that the application is properly installed, thus allowing it to execute normally.

Once the application has been sequenced, all further instances of it execute within the virtualization layer, where any additional changes -- for example, modifying options or otherwise personalizing the application -- continue to be sandboxed and redirected to the reserved storage. Depending on the level of isolation provided by the application virtualization platform, this sandboxing process can capture some or all changes made by the application, merging them with the local file system at runtime. A good example would be a word processor -- the document you save to the local disk might be allowed to pass through the virtualization layer, while changes to the spell-checking or auto-formatting options would typically be redirected to the application's private sandbox.

It's this combination of sequencing and redirecting subsequent changes to the sandbox that makes application virtualization so attractive from a mobile computing standpoint. Because the application runs within the virtualization layer, the components it requires and the changes it makes to them at runtime are isolated from the underlying host system. Add to this the potential sandboxing of personalization changes (and in some cases, data files generated by the application) and you begin to see how this could provide a mobile user newfound flexibility. With everything kept together in the application's sandbox, you can literally move from system to system, plugging and unplugging your workspace as you go.

Such an approach -- using application virtualization to isolate and abstract the workspace from the host system -- has a number of natural advantages over the more familiar virtual machine model. For starters, there's less overhead. Though virtualized in terms of its interaction with specific files and shared resources (such as the Registry), a sandboxed application still executes natively as if it were any other locally installed application. This means that the application runs with the full performance and fidelity of the local machine, including access to hardware resources such as printers, faxes, and even acceleration via DirectX. It also means that the application can be configured to leverage existing shared libraries -- for example, a sandboxed .Net application being able to access a locally installed (that is, not sandboxed) copy of the .Net framework.

By contrast, a VM-based workspace incurs an immediate performance penalty simply because the virtualization layer is much deeper and must host an entire operating system along with the desired application. Anything that the application requires -- drivers, frameworks, shared libraries -- must be installed within the VM, adding to its memory requirements and disk footprint. And unlike sandboxed applications, VM-hosted applications don't reap the benefits of local hardware acceleration, except in the rare case of VMware Workstation, which achieved support for hardware acceleration only recently.

The ultimate argument, however, in favor of sandboxing over VM hosting has to be the raw simplicity of deployment. With a sandboxed application, in most cases you simply launch an executable file and start working. With a VM, you need to install, at minimum, some kind of playback application and then hope that its various pass-through mechanisms support the local hardware environment. If the PC is memory constrained or if you don't have permission to install software (the kiosk/locked-down desktop scenario I noted earlier), you may be out of luck. Sandboxing overcomes this hurdle. Few Windows PCs will have trouble loading a simple executable file -- assuming, of course, you can attach your portable media to the system.