This is the fourth post in my series about application virtualization. One of the products I listed in my last post was Xenocode Virtual Application Studio. Since then, I’ve tested this tool and was a bit surprised how easy it is to handle.
- Pip install Boto3 - Thu, Mar 24 2022
- Install Boto3 (AWS SDK for Python) in Visual Studio Code (VS Code) on Windows - Wed, Feb 23 2022
- Automatically mount an NVMe EBS volume in an EC2 Linux instance using fstab - Mon, Feb 21 2022
However, my first attempt to install the tool failed. The MSIInstaller complained that “C:\Program Files\Common Files\ODBC\Data Sources\” was missing. It was a Vista machine and so I thought it was a compatibility issue. Installation under Windows XP was done in a less than a minute. A few days later I tried it again on the same Vista PC and that time, the installation ran through without problems.
I had never worked with an application virtualization solution before, which didn’t stop me from playing with the tool without reading the documentation. To my surprise, my first virtual application was running a few minutes later on another desktop. Xenocode’s user interface is self-explanatory. If you have any experience creating installation packages for a software deployment solution, you will feel at home immediately.
First, you have to capture a snapshot of your master PC. Xenocode will scan the file system and the registry. Next, you have to launch the setup file of your application. After the installation is finished, Xenocode will determine what files and what registry entries have been added to your system. This packaging technique is sometimes called the differential method. I personally prefer those packagers that intercept the setup routine to capture system changes. The problem with the differential method is that if the source and target PC differ in any significant way, your application might not run properly, for example in a case where a certain DLL is available on the source system but not on the target PC.
Anyway, my first virtualized application (Firefox) worked flawlessly on my target system machine. Xenotype created an exe file (the virtual application) which contained everything that Firefox required to run (the application, DLLs, registry entries). I created the virtual application on an XP machine and started it without problems on Vista and on Windows Server 2003.
I used Microsoft’s Process Monitor to see if it would make changes to the target system when I launched the virtual application. The virtual application made a couple of changes to the file system and the registry of the target PC. However, the virtualized app (Firefox) only wrote to its so-called sandbox. Firefox usually stores its settings in the AppData folder in the user profile. Xenocode redirects these write accesses to the sandbox which is also a folder in the user profile. If you create a bookmark, for example, it will be stored in this sandbox and not in the usual location.
However, it is possible to access the host system from the virtualized application. I saved an html file on the host’s desktop which was not redirected. Of course, this is a necessary feature because you have to be able to share files sometimes. But this demonstrates that application virtualization is quite different from other virtualization solutions. There is no clear separation between the virtualized environment and the host system.
I think this also shows that you can’t be 100% sure that application virtualization won’t change the host system. It depends on the cleverness of the virtualization solution in redirecting the right read and write accesses. It seems to me that Xenocode does not always succeed here. For example, I saw a couple of failed read accesses to “C:\Programs\Firefox”. This didn’t affect the Firefox application though.
I also think that that the term “sandbox” is a bit misleading because this is only a folder where the virtualized application stores its settings. This doesn’t mean that the application itself is running in a sandbox. Task Manager displays its process the same way as any other Windows process. Also, if you kill the process of the virtual application, the virtualized application will continue running. So maybe the term application virtualization is a bit misleading as well.
Firefox is a fairly simple program. So I virtualized Office 2003 to see how Xenocode would cope with complex applications. The virtual application contained Word, Excel, Outlook and Powerpoint. As before, my source PC was running XP and the target machine, Vista. To launch a specific application one can start the virtual application with a certain parameter, for example with “office word”. This has to be configured with Virtual Application Studio though.
Of course is a bit cumbersome for end users to launch an office app from the command prompt. It probably makes more sense to just create one virtual application for each virtualized application. Another option is to create an MSI package which contains shortcuts for the virtualized applications. Xenocode Virtual Application Studio enables you to create an MSI file which can contain multiple virtualized applications with their shortcuts. You can also associate file types with virtualized applications this way.
For example, if you want to deploy Word 2007, you might want to associate .doc and .docx with your virtual application. I think it is one of the downsides of application virtualization that one has to do this manually. Some apps use quite a few file associations, so this could be time consuming. I think this is a typical example of where the separation of applications from the operating system can cause problems.
Another problem occurs if applications have to share data. Xenocode has a solution for this problem though, the so-called XLayer. This feature allows you to share virtual application settings and runtimes. For instance, you could integrate a certain version of the .NET framework which will be shared among the virtualized applications. For other virtualized applications you could use another .NET version.
Subscribe to 4sysops newsletter!
My overall impression of Xenocode Virtual Application Studio is positive. During my tests everything worked flawlessly, except for the problem I had in the beginning with Vista. But this might have been caused by a problem with my test machine. Playing with Xenocode made me more interested in application virtualization, although I still have some reservations about the technology as such.
Great review!
For what it’s worth, I just gave it a shot as well (I used a clean virtual machine as my master PC), and it does not support the Cisco VPN client 😉
Also, if your application requires a reboot during setup, make sure you save the capture/ouput before doing the actual reboot. I didn’t read the documentation, so I found out the hard way. Thinstall supports rebooting during the setup process, without having to do anything.
Would it be possible to include the cost of the application in the articles in this series (assuming it’s available)? Thanks!
Thanks! I think there are quite a few things one will find out the hard way when working with application virtualization. Even though Xenocode’s user interface is self-explanatory, many things are different compared to normal software deployment. I will include the prices if I can find them on the vendor’s site. I agree that the price is an essential feature, too.
Hmm, could this gives the possibility to make a application, put it on a USB stick, and take this around with you? Hence for example, always have the exact same Firefox on you?
Yes that would work, but most of these solutions are too costly. I suggest you look at MojoPac, I believe they have a free for personal use version.