What is app virtualization? Part 2: Virtual "locally installed" apps

In this article, we're going to cover what could broadly be defined as "locally installed" virtual apps.

This article is Part 2 in a series about app virtualization. The other parts are:

In this article, we’re going to cover what could broadly be defined as “locally installed” virtual apps. Part 1 (remote apps) was all about virtual apps that run on a remote server with just a moving picture of the user interface presented on the client device. “Locally installed” virtual apps are a different thing entirely, as they actually run locally on the client computer itself.

In Part 1, I talked a bit about the challenges of managing applications on Windows, including how different applications might conflict with each other. But what if you could put the applications on a Windows computer in a way that they were all isolated from each other so they didn’t conflict? In a nutshell, that’s what locally installed virtual application are!

A simple example

I’ll illustrate this with a simple example. (For techies, this is a very fake simple example, but it illustrates the point.)

Imagine that Application Alpha needs to put an important DLL into the main Windows folder, like this:


Now imagine you install Application Bravo, which also needs to put an important DLL into the main Windows folder. When Bravo is installed, it just puts the file there, like this:


Looks the same, right?

But in this case, c:\windows\important.dll is actually the version that Bravo put there, so when Alpha tries to access it, that DLL is the wrong version, and Alpha doesn’t like it, so it crashes!

“Oh no!”, the user thinks, “Installing Bravo broke Alpha, so I’ll just uninstall Bravo to fix Alpha."

When the user does that, Bravo’s uninstallation program removes c:\windows\important.dll (since it knows that it put it there). Then the user tries to use Alpha again, and it still doesn’t work, this time not because c:\windows\important.dll is the wrong version, but because important.dll is just flat out gone!

Maybe re-installing Alpha fixes it, maybe not. The bigger problem is that your Windows system is now sort of messed up, and the the user has to make a decision between whether they use Alpha or Bravo since they can’t use both. Now imagine an enterprise desktop environment with hundreds of applications that each require hundreds of files, and things can get hairy really fast!

App virtualization to the rescue!

Now let’s imagine the same scenario with locally installed app virtualization in the mix. We’ll use a fake app virt product called AppHero in this example.

So if you have AppHero app virtualization installed on that computer, the AppHero software installs a low level disk driver that sits in between Windows and the file system on the hard drive. (This is very common. For example, this is how Antivirus products work to automatically scan and protect every file in your system.)

So now whenever anything reads or writes a file to the disk drive, that operation is shunted through AppHero.

Going back to our previous example, when Application Alpha is installed, it will try to put important.dll into the c:\windows folder. But AppHero sees this and says, “Hey, c:\windows is important, so I’m not really going to let Alpha put anything there. Instead I’m going to put Alpha’s important.dll somewhere else.”

So the installation program for Alpha thinks it’s putting a file at c:\windows\important.dll, but AppHero intercepts that and instead puts it somewhere else, like this:


Now whenever Alpha requests c:\windows\important.dll, the AppHero low level disk driver actually connects Alpha to c:\AppHero\Alpha\windows\important.dll. The best part about this is that Alpha has no idea this is going on!

The beauty of this is clear when Application Beta is installed. Again Beta tries to copy the file to c:\windows\important.dll, but the AppHero disk driver sees that and instead puts Beta’s copy somewhere else too, like this:


AppHero keeps track of which files it put in alternate locations for which apps, so Alpha and Beta can both blindly access c:\windows\important.dll with AppHero actually connecting them to their own copies. And even if those two DLL files totally conflict, it doesn’t matter because AppHero actually put them all somewhere else!

In fact if we look at the actual files on the disk drive, it would look something like this:


Freaking awesome!

But wait, there’s more!

Keep in mind that in real life, each Windows application might have dozens or even hundreds of files. AppHero can silently locate every single file for every app in some alternate (and safe) location.

The other benefit of this is that it makes adding and removing applications a cinch! For example, if you wanted to remove an application, you don’t have to go through the application’s official uninstallation program and cross your fingers. Instead you can just say, “Hey AppHero, I’m done with Application Bravo, so you can delete it,” and then in one fell swoop, AppHero can just delete its own secret folder with all of Bravo’s files. It’s quick and easy and there’s no chance of breaking anything because everything that needs to be deleted is all in once place! (I should mention that in Part 1 we also talked about how Windows has a database of configuration settings called “the registry”; app virtualization products can also intercept that and store parts of it in hidden fake locations on a per-application basis too.)

App “packaging"

In addition to preventing conflicts and the ease of removing locally installed virtual apps, this technology also makes it really easy to install virtual apps!

Think about it. If the AppHero saw every file and every registry key that each application uses (which is does so it can move them to the secret locations), then that means that instead of running every application’s installation program on every computer where you want to use the app, couldn’t you just grab the whole secret folder with all the real files in fake locations that an application needs and just copy that to another computer and then BOOM! that app is now “installed” on that new computer?


So if I’m an IT pro with thousands of users, and I decide I want to use AppHero, I’m not going to run an application’s installation program on every computer where I want the app. Instead:

  1. I’m going to build a fresh clean Windows computer in my office with no applications.
  2. Then I’m going to install the AppHero app virtualization product
  3. Then I’m going to install one application (e.g. Application Alpha). When this happens, AppHero will see all the files and registry keys that Application Alpha puts on the system and it will redirect them to that secret location.
  4. Then I’ll just grab everything from Application Alpha from that secret location, maybe zip it up into a single convenient file, and now I have everything I need for that app!

Then in order to “install” that app onto a user’s computer, really the only thing I need is the AppHero app virtualization engine and I can just drop my bundled-up zip file which has everything that app needs all setup for the AppHero secret location. It’s fast and easy to do, and I have high confidence that the app will actually work since AppHero is faking everything. Even if the user’s computer has lots of other apps that are installed in the traditional non-virtual way, I still know my new app will work since AppHero will be managing my app’s access to its files and registry settings.

So what kind of products work in the way that I described today? Very broadly speaking, this is how “traditional” app virtualization products work, like Microsoft App-V, VMware ThinApp, Spoon, Ceedo, Numecent, Sandboxie, etc.

Advantages of locally installed virtual apps

  • Since the files the application needs to run are actually on the local client computer, they can be used offline (e.g. with no connection to the remote app server like with remote apps).
  • No network bandwidth is used with locally installed virtual apps, and you don’t have to worry about network performance or network latency.
  • You don’t have to worry about remote servers “going down” or internet weirdness creating a bad experience.
  • Remote servers are not needed to run the app, meaning the infrastructure costs are much lower.
  • Locally installed virtual apps have full access to all local peripherals, including high-bandwidth things like cameras and USB devices.
  • Apps that have high graphical content, including videos, work fine, since the app is running locally on the client.
  • Adding and removing locally installed virtual apps is easy since the apps aren’t really “installed.”

Disadvantages of locally installed virtual apps

  • Windows apps still require a Windows client. So you can’t use locally installed virtual Windows apps on a Mac or an iPad. (Though you can combine locally installed virtual apps with other VM technologies—something I’ll cover in a future part of this series.)
  • Generally speaking, you can’t use locally installed virtual apps with thin clients since thin clients aren’t real Windows computers.
  • Since you need Windows on the client computer, that means you still have to manage all these client computers and client Windows installations (patching, fixing, maintaining, etc.) It’s not like remote apps where all management is done on the remote servers.
  • Locally installed virtual apps use the computing resources of the client computer, which is a double-edged sword. On the one hand, you don’t have to pay for servers, but on the other, a slow or bogged-down client computer will mean the locally installed virtual app is slow too. (Compare this to remote apps which run fine on old or slow computers since the apps themselves are running on remote servers.)
  • Some Windows applications do weird things that are not compatible with locally installed app virtualization.
  • Sometimes the app virtualization products are “too good”, meaning it can be a challenge when multiple apps need to work together because they’re all hidden from each other!

So that’s the low down on locally installed virtual apps. Tune in next week for Part 3! We still need to talk about layering, streaming, apps from virtual disks, dynamically enabling and disabling (or “showing” and “hiding” apps), and probably a bunch of other things I’m forgetting.

Dig Deeper on Application virtualization and streaming