CRN names Cameyo one of the "Top 21 Cloud Vendors to Know in 2021" Read the CRN Article



Offline application virtualization, sometimes called containerization, was a relatively old technique for packaging entire software into a package file, which can then be directly executed on a computer without having to install the virtualized software. Offline app 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: Thinapp, Spoon (the latter requires some browser plugins and streaming agents, therefore it may be considered as not truly agent-less)


Agent-dependent technologies typically install drivers and work at the OS Kernel layer.

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 must 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.


With agent-less virtualization technology, a virtual application is a standalone, self-sufficient .EXE file. You can simply copy & paste it onto a USB disk-on- key and give it to an employee who brought his 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.



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.


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).

In Disk mode, the engine will try 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.

In RAM mode, the engine will try to let the OS do as much as possible (for the same reasons), but it substitutes a more substantial part of the OS such as process loading, file reading / mapping.


A Cameyo virtual application is a self-contained composition of virtualization modules plus the virtual application’s environment. 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” files that don’t really exist. 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.

Often the PROG and DATA folders can live in different places (including local / network).


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.


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.


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.


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.


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 on 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 users to get familiar with application virtualization products, and also supports existing VMWare Thinapp packages.

To transform a Thinapp package into HTML5:


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 Windows applications can run on Linux platforms, and is at a Beta phase. We are also working on capability for running Cameyo apps within the browser, from any device.


There is no doubt that cloud computing, IT consumerization and Web 2.0 are creating a perfect storm towards heterogeneous systems and mobile applications.