Application virtualization as you guessed it, just means to run a software on the local operating system instead of running a full-fledged operating system on top of the actual one. Well, actually “virtualization” is probably a bit too strong of a word and I would rather call it sandboxing in this context as ThinApp doesn’t offer you, for example, to run a Win9x-only software on your local XP or Vista machine, but instead just makes sure that the running program can not fiddle with the operating system’s or user’s settings in the local machine, which is done by rerouting the most of its read-write operation to a sandbox “cache” containing the files and settings for this program.

The first advantages we can think of by reading this is security, which is the reason why some utilities like Sandboxie got popular, as a sandboxed program has very limited rights over the parent operating system and as such dramatically limits the risks of a permanent malware-infection by limiting the scope of a particular program. But as I said, Sandboxie existed for this purpose already, so what has ThinApp that makes it more than a simple sandboxing application?

The strongest point of ThinApp is quite clearly to be able to turn (almost) any software requiring an installation to its portable equivalent. Portable software are quite popular nowadays as people like to carry out their software with them on an USB thumb-drives or other external storage means and use them on any machine without “soiling” it or leaving traces endangering their privacy, which is particularly important when you use machines at a cybercafe for example. Being able to carry all your applications with you on an external media rather than bringing your laptop around certainly seems appealing, but unfortunately, turning a software portable has traditionally been a big hassle if the application developer didn’t think about this feature right from the design phase or amended it to support it afterwards. As such, turning big software like Microsoft Office to a perfectly portable equivalent turns out to be a quite difficult if not impossible at all, as such complex software usually rely on a lot of dependencies like DLL files to COM objects or settings needing to be registered in the Operating System’s registry. Some portable aficionados usually write launchers to register the specific components and settings before running the application itself and cleaning up once it has terminated but this approach clearly is time-consuming to develop and not 100% reliable (if the launcher program gets killed for some reason or if the machine crashes or if a power failure happens, your traces will remain until you clean them up manually).

And it is precisely what ThinApp excels at: making portable software a breeze by eliminating the need to write complex and inherently unreliable wrappers. The approach chosen by VMWare here is very straightforward as it relies on the traditional system usually used in application repackaging applications of creating two snapshots of the current system, before the application installation and after, and compare the changes to generate the differences. To be honest, I’m always a bit anxious with this method as there is no guarantee that it won’t capture unrelated stuff that the operating system was doing in the background and is one of the many reasons why I avoid application repackaging at any cost. ThinApp warns you before the first comparison to only execute this process on a clean XP machine to compensate this, but most of the time, repackaging setup suites allows you to check what the capture process has caught and eliminate any unrelated registry entry or file by yourself in an appropriate user-interface, but it isn’t the case here: if you want to check the results of the comparison process, you will have to dig into the directory structure and registry text files created at the end of the process. ThinApp clearly lacks many integrated conveniences over controlling the generated build, as we will see again a bit later. At any rate, this isn’t an as big issue as with application deployment as the build is going to run in a sandboxed/virtualized environment anyway and does not risk to mess up with the operating system, so this may be deemed acceptable and creating portable builds in a matter of minutes obviously comes at a price.

A clean PC is required to make sure to integrate all the dependencies and get the most compatible package
A clean PC is required to make sure to integrate all the dependencies and get the most compatible package.

So, I unpacked an already made and pristine XP virtual machine (I keep my virtual machines in 7z SFX archives so I can unpack them easily whenever I need and be sure that I don’t tamper with them by running them accidentally) and installed ThinApp on it, which has a quick and straightforward installation process not requiring a reboot at the end of process. I then started ThinApp and made the first snapshot, then installed Microsoft Office 2003 from a network share and made the second snapshot. Further in the process, you get the opportunity to restrict the usage of this package to specific Active Directory groups only and choose where the application’s user files should be stored : in user’s profile %APPDATA%\ThInstall, in the same directory as the package (best choice for 100% portable software leaving no traces) or to a specific location like a network share. You can even, optionally, decide to build an accompanying MSI file to deploy shortcuts to the virtualized launchers to the applications.

The most disappointing part in terms of user experience (and of this product altogether) comes from the build part. You need to be very cautious here because the questions won’t be asked twice and there is not any other way to reload your project once you close ThinApp. Surprisingly, there is no “Load project” anywhere at the start of this wizard-driven application, and the only way to make later changes is to edit the generation batch files manually. Not exactly great in 2008 and for a software reaching its fourth version and as such supposedly rather mature.

The Beauty and the Beast : awesome virtualization technology but the building user-experience relies on a batch file ?
The Beauty and the Beast: awesome virtualization technology but the building UX relies on a 80-ish batch file?

I then copied the resulting build to my own machine, deleted the virtual machine previously used for the build, unpacked another fresh one for testing, copied the package directory to this virtual machine and started launching Excel (which is done technically by running a wrapper) which popped up right away. There was no noticeable speed difference at all using this build instead of a fully installed version. Any configuration change in Excel is saved properly in the sandbox’s directory and remains stored so it remembers the changes even on a subsequent runs.

The application wrapper: when launched, a small window appears at the bottom right of the screen to indicate the original application is loading.
The application wrapper: a small window appears on the screen to indicate the original application is loading.

I went further on and wanted to make sure that this package didn’t write any temporary file anywhere else than in its own directory (I had chosen they should reside in the same directory as the package back at the build process) when running. I then unpacked a fresh virtual machine to do this testing and installed InstallRite before launching the virtualized Office package. InstallRite is a free repackaging software that I was talking about a bit earlier. While I, as I said, avoid repackaging at all costs, it is a very helpful companion to trace the changes an application makes to both the file system and the registry between a first and second snapshot. I hence used made a first snapshot before running the virtualized Excel and when it was running and was delighted to see that all the files created ended up in the package’s directory, just as it should. I did a second snapshot after having exited Excel and yet again there were no files or registry entries elsewhere.

Obviously, after this very successful experiment, we can leave our imagination wander and think about how to make the most out of this technology aside from carrying around your software for personal use. We could for example imagine to have the applications reside on a network share and users running them from there. If we think about it, this way to do things would give numerous advantages: first, deploying new software would be as easy as putting it available to a share the users already have access to, instead of pushing it to every workstations on the network. In the same manner, the applications upgrades from one version to another would be as easy as making the new version’s package available in the same share without taking care of potential issues during the upgrades or again pushing it again to a good number of machines. Of course, working with applications from the network used by many people at the same time may put the latter to its knees, but for example a logon script may copy the new virtualized package files to each machine’s hard drive as they are placed on the share. Unfortunately, Office is a rather bad candidate for this as the file associations won’t work unless the Office Setup program is ran on the local machine or recreating them manually or via script to make them call the virtualized version, but that’s probably as much hassle as installing the software in the first place, but it may be a great approach for rarely used and/or sensible software.

Given the great success of the Office experiment, I decided to give the thing a bigger challenge and tried to make a portable package of the Hamachi software-based VPN software. Hamachi creates a new network connection on the Windows network and I was curious to see if it would work and sure enough it didn’t, most likely because of the fact that it runs sandboxed, which prevents this kind of modification of the OS and that as such, it cannot be aware of the existence of the network connection created by Hamachi. It is a shame because it would have been useful in some circumstances to use this to share some files, support remotely, or even play LAN-based games with a remote person, without leaving traces on his PC after the session, but I wasn’t really expecting this to work in the first place anyway as it was going against too many of the sandbox concepts and principles.

As a conclusion, ThinApp is an application meeting its objectives and the fact it manages to virtualize even very complex applications without leaving any traces or requiring some kind of software agent preinstalled on the machine is very impressive. However, it is a pity to see such a great technology to have so many settings and features not exposed from the UI: not being able to reload previously made packages to make small changes but instead having to change things in batch files (which always feels not unreliable for Enterprise-class products) or package’s internal files (like the registry ones) is a major pain. More control over what is integrated in the build as the result of the two snapshots comparison from an intuitive user-interface would be a very welcome addition as well. I assume that VMWare deemed that this tool would only be used by tech-savvy people and IT professionals, which is true, but it shouldn't prevent from including the conveniences they are used to and make them more efficient and productive.

Rating: 7.5/10