A
PPLICATION
V
IRTUALIZATION
T
ECHNOLOGIES
WHITEPAPER
2 | P a g e
INTRODUCTION
TWO TECHNOLOGY CATEGORIES
Application virtualization technologies can be divided into two main categories: those that require an agent to be installed on each endpoint in order to run virtual applications, and those that don’t. This may sound like a small difference, but it implies some very deep architectural differences, inherent advantages and limitations.
Examples of agent-dependent products: App-V, Numecent, Symantec Workspace Virtualization.
Examples of agent-less products: Cameyo, Thinapp, Spoon (the latter requires some browser plugins and streaming agents, therefore it may be considered as not truly agent-less)
KERNEL VS USER-MODE
Agent-dependent technologies typically install drivers and work at the OS Kernel layer. They install system-wide filesystem & registry filters.
Pros of Kernel-mode agents:
• Can « see » everything on the system.
• Can virtualize installers and system processes, not just the virtual application itself. Makes inter-process communication easier between virtual and non-virtual applications.
• Kernel-mode virtualization engines are built in a more Microsoft-documented / recommended way.
Cons of Kernel-mode agents :
• Vulnerability in a driver can lead to system-wide security vulnerability. • Intrusive: can have performance impact on the entire system.
• Requires administrator privileges to install / update.
• Bugs in kernel-mode agents can lead to serious crashes (BSOD / system-wide corruption). • Makes the patching of the application virtualization engine itself more complex / risky.
i.e: if you need to upgrade the virtualization engine just to resolve an issue with one specific virtual application, you have to upgrade the entire virtualization agent and hence proceed with a full test-deployment cycle. With agent-less products you can update the specific application without affecting other virtual applications.
BYOD& PORTABILITY
3 | P a g e
laptop, or email it to him so that he can work from home. Obviously this is not doable with agent-dependent virtualization, and will never be.
This is also a barrier for BYOD: you cannot require your employees to install drivers and system-wide agents on their personal computers.
According to analysts, there is an inevitable trend towards BYOD and app stores (both internal to a company, and external). Agent-dependent virtualization is not an option on app stores.
IMPLEMENTATION
THE KERNEL-MODE IMPLEMENTATION (AGENT-DEPENDENT)
A kernel-mode driver intercepts all filesystem & registry activity on the system. It then merges the view of the virtual application with that of the real system. It can merge the views either for the virtual application itself (isolated mode) or for the entire system, thus giving the impression that the program is truly installed.
THE USER-MODE IMPLEMENTATION
User-mode virtualization products function in one of two ways:
• RAM mode: file readings are redirected directly to the virtual package. Also replaces the OS process loader with a “skeleton executable”, and substitutes the OS process loading. This approach results in smaller disk space used by virtual applications. However this approach does not benefit from the operating system’s native benefits (in terms of performance, caching, section sharing, backup & ease of access to files, and everything the OS’ file system has to offer). • Disk mode: the first time a virtual file is read by the application, the virtualization engine
extracts it on disk and redirects the file I/O to it. This approach results in larger disk occupation and takes longer during the first application launch. But it is practically as fast as native file I/O. Also, it is optimal for offline application caching (i.e. when running a virtual package from a server).
CAMEYO’S VIRTUALIZATION
Cameyo offers both virtualization modes: RAM and Disk. The administrator / packager can choose which mode he prefers, or switch from one to another.
In Disk mode, Cameyo tries to let the OS do most of the work without interference: process loading, file I/O (despite path redirection), registry APIs (despite path redirection). This lowers the dependency on OS versions and ensures greater compatibility with different versions of Windows.
4 | P a g e
CAMEYO PACKAGE FILE FORMAT
A Cameyo virtual application is a self-contained composition of virtualization modules plus the virtual application’s files and registry. The virtualization modules & files are contained within each Cameyo virtual app (.cameyo.exe file). They contain:
• VirtApp.ini: contains the different application properties which determine the virtualization’s behavior. Note: this file is not extracted on disk, but can be viewed by launching the virtual application with the parameter “-ShowIni”.
• Virtual engine (AppVirtDll.dll, AppVirtDll64.dll): this DLL engine is injected into the virtual applications’ processes to make them “see” the virtual environment merged together with the host system. By default it is also injected into child processes executed by the virtual application, even if they are not part of the virtualization package.
• Loader (Loader.exe): the virtual application package is concatenated to the “tail” of this
executable file (or alternatively it can be left as a standalone .DAT file in the same directory and with the same name as the loader).
• The virtual filesystem database (VirtFiles.db): we call it “the Matrix”. This database holds the state of each of the application’s virtual files.
• VirtReg.dat: virtual application’s registry hive.
• SandboxCfg.db: per-folder sandboxing settings that determines how to merge / isolate specific filesystem folders and registry keys.
• VFC (virtual file container): contains the application’s files in a proprietary format. These modules extract into the application’s repository directory, which is by default
%AppData%\VOS\[AppID]. By default, the repository directory structure for a virtual application looks like this:
• Root (\): the above mentioned modules
• PROG: the application’s files. When running in RAM mode, this directory will have little inside of it. When in Disk mode, application’s files will be extracted on a per-need-basis (in addition to some pre-extracted files).
• DATA: the user’s changes.
In professional Cameyo versions, the PROG and DATA folders can live in different places (including local / network).
SELF-CONTAINED PACKAGES
Cameyo packages are self-contained. Meaning you don’t need to keep project “source files” or rebuild the package every time you want to change something in it. You can simply take a Cameyo’s executable (.cameyo.exe) and modify it. This makes it easier to work with different versions of virtual applications.
5 | P a g e
When a new version of an application is available, it is enough to replace the .cameyo.exe executable file with the newer version. The next time the user will launch it, the PROG folder will be replaced by the newer version, while the user’s settings will remain unchanged.
DEPLOYMENT & DISTRIBUTION
Cameyo applications can be deployed in several ways: as a .cameyo.exe executable on which the user can click, or by integrating shortcuts to the user’s Start menu and desktop, where the application would have placed them. Running virtual applications with the parameter “-FullIntegrate” copies the
application package locally and creates the corresponding shortcuts. Both operations occur only the first time.
MANAGEABILITY, CUSTOMIZATION AND AUTOMATION
Practically every aspect of Cameyo can be automated via the command line. Starting from capture / packaging, to changing application settings, to monitoring the application’s runtime and removing it. Cameyo also offers an SDK; the same SDK with which the Cameyo Package Editor was built. The Package Editor itself is open-source and available on Google Code.
ONLINE PACKAGING
Thanks to its automation capabilities, Cameyo is the only product capable of packaging applications directly from the cloud, by simply submitting an installer; even installers that do not support silent installation arguments. The Online Packager is openly accessible. Internet users around the world produce an average of one virtual package every 10 minutes. In average, it takes about one minute for a virtual package to be built using the Online Packager.
This technology allows many users to get familiar with application virtualization, and provides a great amount of feedback for testing & improving the Cameyo virtualization engine against different kinds of software.
THE NEED FOR SIMPLICITY
Application virtualization products are quite complex to master. Their learning curve is longer than most IT products, because virtualizing software is a complex subject. At the age of Web 2.0 and touch-based software, we believe that such level of complexity is not justified, especially for smaller projects where application virtualization is just a part of bigger projects and is used for solving pinpoint problems such as XP migration, BYOD. We believe that application virtualization packaging should be usable by any IT professional, regardless of their virtualization / packaging expertise.
CAMEYO: THE ROAD AHEAD
6 | P a g e
Alpha stage. We are also working on capability for running Cameyo apps within the browser, from any device.
