Cloud drive virtualization


Streaming Windows cloud-based applications through HTML5 is a relatively new domain. But using applications in a browser is only useful if coupled with persistent user storage. How useful can HTML5 applications be if users cannot save persistent data? For this very reason, we created a technology which we call Cloud Drive Virtualization.

HTML5 applications execute on a distant server’s CPU and are rendered through HTML5. There are two traditional ways of coupling storage to remote sessions:

Data storage approach #1: direct access

This is the oldest, simplest method: RDP or HTML5 sessions run on a server which directly has access to the company’s network resources where users can save & load data. This method is convenient for LAN scenarios. However, it is neither practical nor effective when it comes to Internet / cloud / distributed scenarios.

Data storage approach #2: synchronization

This method is about downloading the entire user’s data onto the remote server where applications are to be executed. Much like a roaming profile, the user’s data is first copied onto the local machine, and changes are then synchronized back to the remote (or cloud) storage server. This is the usual method when it comes to Windows platforms. It is also used by some HTML5 products. It comes with some inherent flaws:

  • Efficiency: copying the entire user’s data between servers before each session begins is inefficient both in terms of network traffic and storage. Nowadays storage is counted in Terabytes. Providers like Google, Dropbox and OneDrive offer 1 TB of cloud storage at only a few dollars a month. Assume you have just 50 users – it’s easy to do the math of how much traffic needs to go back and forth between the HTML5 server and storage servers each time a user starts a session. If you plan on hosting your HTML5 server at a cloud provider, take into account additional network costs. Additionally, consider how much space capacity is required on each HTML5 server.
  • Security: cloud storage providers are putting in place tremendous resources for securing their users’ data. Downloading users’ data to a remote-execution HTML5 server effectively reduces the security of that data, becoming the weakest link in the security chain – the easiest target for hackers (arguably easier than aiming at highly-secured datacenters such as Dropbox’s). Do users truly want to see their cloud data downloaded to HTML5 server, increasing their surface of attack?
  • Startup speed: perhaps a detail but not negligible, the time required for downloading the entire user’s data is one more barrier to adoption. Waiting additional time for HTML5 sessions to be “data-ready” may seem quite long for users.

The Cameyo approach

Cloud drive virtualization gives you access to your cloud data without the stated disadvantages. During HTML5 sessions, a virtual storage folder is displayed inside the Desktop folder:


When you enter this folder from a virtual application (for example during File | Open dialogs), your cloud storage is accessed behind-the-scenes and provides the file listing and information to the application as if it were a local Windows folder. Thus the application sees the folder’s contents as if they were local, while in fact its contents are fetched in real-time and simulated to the application. But the file’s contents are not yet downloaded to our HTML5 server. Then, you choose to open any of the files inside (e.g. for viewing / editing it), this is when your cloud drive files are actually copied into the execution server. You can then work on them and any modification will be synchronized back to your cloud drive.

Distant storage appears as a local directory:


How does it work?

Storage virtualization is accomplished thanks to file-system virtualization engine. As you may already know, application virtualization engine generates a 2-way view for virtual applications: the local file-system merged with the virtual application’s files. When running in the HTML5 environment, our engine now generates a 3-way view, combining the local file-system, the virtual application’s files, and your cloud storage.


When your HTML5 session is finished, any cloud files we downloaded are destroyed. In fact any data generated during your session is erased.

This technology is available to Cameyo users for free, both in our cloud and on-premise HTML5 servers. You can add several cloud drives at the same time. The currently supported providers are Dropbox and Google Drive.




Have you ever installed software… into your browser?

Probably not. Well, with our latest invention – now you can!

As you know, we love to invent never-done-before stuff, and this one’s our latest addition into Cameyo 3. In fact it’s your user survey responses that has led us to put emphasis on this new trick.

Install .MSI .EXE .ZIP or .TAR files into your… browser. It’s fairly innovative. Try it yourself: (choose “Manual mode”):



A year of Cameyo Play / HTML5

Many of Cameyo 3’s improvements relate to Cameyo Play. That’s no wonder; you are now thousands to use this service every week. We will continue to make it the only service allowing you to add your own applications so easily.

We wanted to share with you our Cameyo Play survey results, kindly taken by 211 users to date:






We hear you loud and clear regarding the most wanted improvements, and are working on bringing you more apps and an improved usage speed first. Note that launch speed was already improved since this survey was published, but of course we will continue improving.

Cameyo 3

News about Cameyo 3:

All of Cameyo 3’s online features, listed in the previous blog article, have been released by now. A white-paper about our HTML5 cloud storage virtualization can be found here.

The desktop version of Cameyo 3 is available for a preview here.

Cameyo 3 apps will also be in Beta level for running under Linux WINE.


Last, allow me to introduce our new GitHub page. We moved the source code from Google Code, which is being deprecated, to

cameyo github

Cameyo 3.0 is just around the corner

Cameyo 3 will bring some major surprises. For the first time, you will be able to use Windows apps on quite a few non-Windows platforms, very easily. Nowadays so many IT professionals need to cope in environments that include more than just Windows. Whether it is because of BYOD or simply the will to migrate to different OSes, Cameyo 3 will open new doors (no pun intended).


  • Native clients for playing Cameyo apps, in addition to the current HTML5 component.
    • Native Android player (preview)
    • Native Windows player with seamless mode support
    • Native Linux player with seamless mode support
    • Perhaps more…
    • Most of these native clients are based on FreeRDP. We will upload their source codes on Github.
  • Storage virtualization: virtual apps can work on distant storage as if it were a local folder. Supported storage types: UNC and Dropbox.
  • Storage virtualization applied to Cameyo Play: once you connect your Dropbox account, Cameyo servers (HTML5 or others) will automatically display a “Dropbox” folder within your Favorites library. You will see your files there and will be able to work on them. Changes are synchronized with your actual Dropbox storage.
  • Self-hosted Play servers (preview): host your own Play servers. Works automatically with HTML5 as well as other native players.
  • CameyoMenu replaced with a lighter CameyoPlayer: weighing just 100KB, this new UI module will allow you to do exactly what you need (and nothing more…): download or Play applications on your Windows workstation. The Packager and Package Editor remain, of course.

Also, allow me to repeat some of the highlights of the most recent Cameyo versions:

  • Data encryption (option): virtual apps encrypt & decrypt in real time whatever’s written on the disk.
  • Cameyo Online Publish: allowing you to upload your own Cameyo packages online and hence play them on HTML5 (and soon Android etc).


Over-the-web installation

During the past few weeks, if you’ve used our Online Packager you may have witnessed a quiet revolution. We call it “over-the-web installation” or “LiveInstall”. Oh, and as with online packaging, we’re pioneering it.

When we built the Online Packager back in 2011, the idea was to simplify application packaging to its bare minimum. Sure, packaging applications is not *that* complicated, and smart folks like you can easily learn how to do it. But even if you do and do it right, on a proper environment; say you want to package an application right now. Do you have your clean virtual machine ready, and do you have the 10-15 minutes to find an available VM, start it, install the software, and package it? Sure you do. But unless you’re a packaging professional, you probably have more important things to do instead. That’s why we invented online packaging: submit, click, done.

Last month we’ve upgraded our online packager so that instead of an average of 3 minutes, it now takes an average of 1 minute to virtualize an application online. But that’s not the scoop. The scoop is: we’ve invented a new way for installing applications through the browser. This allows you to package not only applications with a silent installation mode, but also those that require input / user intervention.

This video shows how this works with an installer that requires manual input:

Video: Over-the-Web Installation

LiveInstall is still at a preliminary state, and won’t work with all scenarios. But we will improve it considerably and keep you posted. Until then, accept this little present for 2014.

RepoSync: simply deploying virtual apps to network machines

RepoSync is a new feature in the next Cameyo 2.6 version. It allows IT administrators to synchronize (deploy / remove) virtual applications from a shared network folder. Applications are copied to local machine’s VOS directory, and their shortcuts & associations are created to provide a look & feel similar to that of an installed application.

The repository can include sub-directories to help organize virtual applications by category.

Virtual applications can be targeted to specific user groups by setting Active Directory permissions on virtual apps (see previous blog post).

In this video you can see how it works. The video includes screens from two machines: that of the managed desktop, and that of the administrator:

RepoSync: synchronizing virtual applications with your network desktops


Active Directory permissions

One of the highlights of the upcoming minor version 2.6 is the ability to control Active Directory permissions for virtual applications.

So I’d like to share with you the configuration screen for this new version, which will be part of the Package Editor:

Active Directory permissions

Active Directory permissions

The first part deals with white-listed domain name(s).

The second part allows you to white-list / black-list user groups, either by name or by SID.

These first two sections are “AND”ed, meaning that if you fill both, they will both have to match in order for the application to launch (or you can enter just one or another: domain name or user groups).

The third section deals with cases where the user is offline. Indeed, the two Active Directory verification sections discussed above require connectivity to the domain server. But what happens if the user is out on a business trip or a just working from somewhere outside the organization without VPN? This section solves this use-case and lets you configure a grace period during which Active Directory authentication won’t be required.

The bottom section “Messages” is self explanatory.

Another functionality that will be coupled with this one is called “RepoSync”. It will synchronize and create shortcuts on the user’s desktop for applications, from a network share. Users will only get the apps they are allowed to, according to this Active Directory dialog. And inversely, apps to which they are no longer entitled will be removed from their desktop.

Any volunteers for Beta testings, please contact cameyo at

The Active Directory features will be available in Cameyo’s Enterprise edition.

Now that 2.5 is out

Cameyo 2.5 has been a considerable piece of work. A new virtualization engine (called “RAM virtualization mode”), the file format has been revamped and optimized for speed (runtime, extraction, editing). Also, application’s original files and user’s changes are now split into two layers, allowing a lot of flexibility in terms of networking, data synchronization, backup.

We’ve also released a commercial offering for enterprises & developers who need more than 49 machines (some of you didn’t realize it, but the Cameyo license has always already been free but limited to 49 machines). You might ask: “I’m not a company yet I want the extended version. Is there a way to buy it?” You can, but contributing to the product by translating, helping with testing, volunteering to write descriptions / screenshots for our library apps, or any other valid idea you may have. In other words, if you’re a home user we don’t want your money – only your good deeds! If you wish to volunteer, contact cameyo at

Now, here’s to what’s new in Cameyo 2.5. But first the video:


Fast! Faster application runtime, file and registry access, first deployment. Faster package editing.
– New RAM virtualization mode: virtual apps run directly from memory, with no disk pre-extraction. DISK virtualization mode still available.
– Application files stored separately from application’s changes: optimized for network / cloud data synchronization. Also allows sharing one single package for different user sessions on terminal servers (extended configuration in Enterprise edition).
New isolation mode: Strictly Isolated, hiding from the virtual application some specific folders and registry keys areas on the host system, to improve compatibility.
Font virtualization.
– Support for huge packages (> 2GB).
– Option for separating application data from executable (.DAT).
– We’ve upgraded our cloud packager. Producing a virtual app on it now takes an average of one minute!
– More command-lines and properties for more flexibility.

Enterprise / Developer editions:
Auto-update: implement your own auto-updates for virtual packages.
– Package password lockdown: prevent anyone other than you from editing virtual packages.
– Command-line XML package builder.
– Export package blueprints (templates).
– Easier, more powerful scripting.
– New expiration mode.
– EULA license display.