Isolation modes are by far the most important thing to fully understand when it comes to ThinApp. Most of the troubleshooting you will face is related to isolation modes in one way or another. Isolation modes are the packager's method of specifying what level of interaction the package is allowed to have with the underlying operating system.
You can specify different isolation modes on a per directory or registry sub-tree basis. Any child will inherit its parent isolation mode if not overridden.
ThinApp offers three different isolation modes.
Merged allows the virtualized application to interact with local files, folders, and registry keys. The package can read local elements and is able to modify local elements. Any new element will be created on the local system. If any of the virtualized elements are modified, the modifications will be stored in the sandbox.
Merged mostly mimics the behavior of a natively installed application. The actions of the package are still subject to the privileges of the user running the application. If the user is not allowed to modify a location, the standard operating system dialog box will be displayed saying so.
WriteCopy will allow the package to read any local elements, but if modified, the modification will end up in the sandbox and not the local system. If you create a new file or registry key in a WriteCopy location, it will be sandboxed. Modifications made to virtualized elements will be sandboxed.
WriteCopy will protect your local system from being modified by a virtualized application. WriteCopy is often used to allow applications demanding higher privileges to be able to executed by a standard user. The application thinks it is capable of modifying C:\Windows but all those operations end up in the sandbox.
Full isolation mode will keep the virtualized application from accessing anything locally on the underlying operating system. Physical elements are hidden from the virtualized application. If you fully isolate a folder, only the folder's virtualized content will be available. New elements or modifications of a virtualized element will end up in the sandbox.
Full is mostly used to protect the virtualized application from seeing conflicting elements present on the local machine. Take for example, your virtualized Microsoft Office 2010 having Microsoft Office 2003 locally installed. If you don't protect the virtualized Office from seeing the old local installation of Office, the virtualized Office 2010 will start to self-repair.
To summarize the differences between the isolation modes, refer to the table given as follows:
|
Isolation mode |
System elements |
Virtual elements |
|---|---|---|
|
Merged mode |
Application can read and modify content. |
Modifications will be sandboxed. |
|
WriteCopy mode |
Application can read content. Modifications will be sandboxed. |
Modifications will be sandboxed. |
|
Full mode |
Application cannot read content. |
Modifications will be sandboxed. |
You specify different isolation modes for folders using a configuration file named ##Attributes.ini located in each folder, as shown in the following screenshot:
The previous screenshot is an example of WriteCopy specified in the %ProgramFilesDir% folder.
In the virtual registry you specify isolation modes in front of the registry sub-tree.
Let's have a look at some isolation mode examples to help you fully understand isolation modes.
On your physical machine you have a file called File.txt within C:\Temp folder.
You have the representation of C:\Temp within your project folder where you specify either Merged or WriteCopy as an isolation mode, as shown in the following screenshot:
Run your virtualized application (in this example, Mozilla Firefox) and browse to C:\ Temp. The application can see the local File.txt file, it can open it and read its content.
Merged and WriteCopy allows for the virtual environment to read and access native files and registry keys.
In the same scenario as the previous example, on your native machine you have C:\Temp\File.txt.
Within your project folder you've specified Full as the isolation mode in the C:\Temp folder.
When you run
your virtualized Mozilla Firefox and browse to C:\Temp, it looks empty, as shown in the following screenshot:
The Full isolation mode hides any native files or registry keys.
You are using
WriteCopy or Full as your isolation mode on C:\Temp. From within your virtualized application you save a file into C:\Temp. The file will be sandboxed and your native machine is kept clean. Your virtualized application sees the file as being located in C:\Temp.
WriteCopy or Full will place new files in the sandbox and keep your physical machine clean. Note that there are different associations for the .html file between the native environment and the virtualized one. We will discuss the file type registrations later in Chapter 3, Deployment of ThinApp Packages.
No matter which one of the isolation modes you use, if a virtual file or registry key is modified, the modification will be stored in the sandbox.
When does a file end up in the sandbox? An application can access a file using one of two methods. It can be read-only, which means no modifications can be made to the file and the ThinApp runtime simply passes the file to the application. But if the application opens a file for writing operations, depending on the isolation mode, the ThinApp runtime will first copy the file into the sandbox and then pass the file to the application. This way ThinApp can guarantee that any writing operation needed can be done immediately to the file. This also means you might end up getting files in your sandbox that have not been modified by either the application or the user. It's not very common but nevertheless something you need to be aware of.
During the
capture process, you're asked what default directory isolation mode you want to use. This is of very little technical importance and is mostly a policy decision. I tend to use WriteCopy as my default isolation mode during packaging and tweaking of the project. This way I know that all I do will be sandboxed. Later, when I compile my production version, I change to Merged as the default directory isolation mode. This way, users are less likely to run into the problem of storing a file somewhere without being able to find the file later on since it has been sandboxed. The default isolation mode is specified within your Package.ini file using the following parameter:
[Isolation] DirectoryIsolationMode=
It's important to point out that you are only asked about the default directory isolation mode and not your default registry isolation mode. The default isolation mode for your registry is always WriteCopy but you can change it within Package.ini.
[Isolation] RegistryIsolationMode=Merged
As a result of the above, the default isolation mode for the registry would be Merged instead of WriteCopy.
During the capture process you are asked about which default directory isolation mode to use, as shown in the previous screenshot.