VMware Thinapp – Isolation Modes Explained


In VMware Thinapp the different isolation modes govern how much access a virtual application has to the physical host OS. With Merged isolation mode our virtual application can save files to the physical host OS just like any other application. With WriteCopy isolation we are restricted to the Desktop and My Documents folders. Full isolation has no access to the physical environment at all.

But how does Thinapp handle run-time changes to the application itself?

Before we get in to the subtleties in behavior between these modes it is important to be clear about the areas impacted by run-time changes in a virtualized application.

First we have the virtualized environment itself which consists of the file system and registry settings that Thinapp captured during the application install.

Next we have the application sandbox (which is typically stored in the User profile). The sandbox is a user specific extension of the virtualized environment.

Finally we have the physical host OS itself.

Note that the following discussion assumes that the virtual application has the appropriate permissions to modify the physical host OS, which of course it might not have in real life.

Let’s look at how the different isolation modes affect access to the physical host OS:

Isolation Mode: Access To The Physical Host OS

Isolation Mode Read Modify
Merged Yes Yes
WriteCopy Yes No
Full No No

Note that read access is limited by the structure of the virtual environment. If, for example, the same file or registry key exists in both the physical and virtual environments then the virtual application will only be able to see the virtual file (or registry key).

Here we can also see that the Merged isolation mode is the only mode that allows the virtual environment to modify the physical environment. We will find though that Merged isolation is limited in terms of what it can modify on the physical host OS.

Merged Isolation Mode: Run-time Modifications

Isolation Mode File or setting already exists in physical environment? File or setting already exists in virtual environment? Modification Destination
Merged N N Physical
Merged Y N Virtual
Merged Y Sandbox

With Merged isolation then we can see that run-time modifications will be made to the physical host OS only if those modifications do not already exist in either the virtual or physical environments.

If the run-time modification does exist in the physical host OS (but not the virtual environment) then it will take effect within the virtual environment. As noted earlier this means that a conflict arises between the physical and virtual environments whereby the virtual application can no longer see the conflicting element(s) that exist in the physical environment.

Finally, any modification that already exists within the virtual environment will be sent to the sandbox.

Now let’s take a look at the WriteCopy isolation mode.

WriteCopy Isolation Mode: Run-time Modifications

Isolation Mode File or setting already exists in physical environment? File or setting already exists in virtual environment? Modification Destination
WriteCopy N N Sandbox
WriteCopy Y N Virtual
WriteCopy Y Sandbox

WriteCopy behaves very much like the Merged isolation mode. The difference is that when the virtual environment tries to “modify” the physical environment these changes are sent to the sandbox.

Otherwise the WriteCopy and Merged isolation modes function in the same way.

This just leaves us with Full isolation, and this is the simplest mode to discuss.

Full Isolation Mode: Run-time Modifications

Isolation Mode File or setting already exists in physical environment? File or setting already exists in virtual environment? Modification Destination
Full N/A N Sandbox
Full N/A Y Sandbox

As we can see all run-time modifications are directed to the sandbox. Full isolation mode cannot read the physical environment at all.

If we take a closer look at the virtualized files and registry keys of a Thinapp project we will find settings for each of the isolation modes on a per folder and per registry key basis.

Each directory, for example, contains an ##Attributes.ini file that tells the application what the isolation mode is for that given folder:

[Isolation]
DirectoryIsolationMode=WriteCopy

Isolation modes for the registry are handled on a per key basis as the following extract from my Firefox 3.6.3 HKEY_CURRENT_USER.txt shows:

isolation_writecopy HKEY_CURRENT_USER\Software\Classes\Local Settings\
Software\Microsoft\Windows\Shell\BagMRU\1\1
Value=MRUListEx
REG_BINARY=#00#00#00#00#ff#ff#ff#ff
Value=0

This flexibility means that if we need to we can manually adjust the isolation modes for any directory or registry key as we see fit, before we build the application for deployment. We are not locked in to the modes that Thinapp initially assigns to the project.

The current version of Thinapp, version 4.5 supports Windows 7 and a 60 day trial is available from VMware: http://www.vmware.com/products/thinapp/.

Source: Thinapp Blog.

Related Posts: ThinappHelper – A Thinapp Utility For The Rest Of Us …

4 thoughts on “VMware Thinapp – Isolation Modes Explained

    1. Take a look at the virtualized files and registry keys of your Thinapp project and you will see ##Attributes.ini for folders and .txt files for registry settings. You can change isolation modes manually in these files to change the modes for that particular folder or registry setting. So you would change the mode to “Merged”.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s