Application Virtualization

Two Types of Application Virtualization

While the previous explanations of virtualization provided a very basic rundown of what defines each type, our categorizing is of necessity roughly based on what reality currently offers. When it comes down to choosing a certain piece of software for a task, we often see big differences promoting the company's definitions of these fields. This is also true for application virtualization, and because its definition is so vague we see these different interpretations surfacing. One technology often described as application virtualization is something many PC users encounter on a daily basis, and it is best understood by naming its most popular examples: the Common Language Runtime environment of the .NET Framework and the Java Virtual Machine.

Though detailing what both these runtime environments do might be an interesting look at this interpretation of application virtualization, they are not the focus of this article. What's important to note is that they have a different take at solving some of the same problems. As any experienced programmer might tell you, an application coded natively for a certain OS can be quite sensitive in its needs for memory management and the specific capabilities of the CPU it runs on. As such, badly programmed applications can easily cause trouble, resulting in huge performance losses or even lockups. Our runtime environments provide a layer between the OS and the application, essentially isolating the application from vital resources of the system. They manage the resources while also providing a portable platform. The software requires the runtime environment to be present, but as long as that requirement is met the software can be run on any system.

Our Primary Focus

The main type of application virtualization we want to shed some light on, however, does not employ quite the same tactic of isolation. Thanks to the different companies developing it, we also get some nice extras, especially in the field of software deployment and distribution.

Put simply, application virtualization provides the possibility to fool an application into believing that some or all of the system resources it accesses and tampers with (on Windows, the most notable examples are the file system and the registry) are actually the real deal, while they are in fact simulated by the application virtualization management software. There are different degrees that the solutions provide when it comes to simulating resources, but the general goal is usually the same: Turning any user level running application, no matter its complexity, into a single, instantly executable package. This package should be completely cut off from the OS it is running on, in that it still requires the same architecture but no longer leaves any footprint on the host machine. This would mean that, whether or not the full, unvirtualized application was previously installed on a different host machine, as long as the manager software is present, the entire application is able to run from the package as if it were freshly installed.

This is achieved by catching every system resource request the application does (such as saving a file or saving something in the system registry) and redirecting it to a simulated version provided by the manager software. While this does allow isolating the app from the system, there are some steps that need to be taken first. The technology actually captures the entirety of the software into a single package, and the only way to do this is by monitoring how the application installation process. The management software captures the changes made to the system during the installation and builds the virtualization layer accordingly, making sure the application can remain blissfully unaware of its isolated state. This allows the application to run from any location, which is where the notion of streaming becomes especially interesting.

In the above image, SVS is getting ready to capture the installation of a program. It will record every single change made by the installer, which will form the basis of the application sandbox.