ThinApp is designed to allow an application to run in a self-contained environment without having to install it to a host operating system in a traditional manner. The application comprises one or more .exe files and a possible .dat file, all located in a single directory. Suppose it is installed as an .msi or is registered with regedit. In that case, shortcuts may be created on the desktop and in the Start Menu, and a few registry entries created to accommodate file and protocol associations. If it is installed as an .msi, further registry entries are created to display the application in Add / Remove Programs or Programs and Features. Aside from these host file system and registry modifications, the installation of the application has no other impact on the host operating system.

 

Sandbox

If the application is isolated from the host system, any changes, deletions, or additions made by the application to the file system or registry are recorded in the sandbox instead of in the host operating system. The sandbox is a directory in which these modifications are recorded. The degree to which these modifications are recorded in the sandbox instead of on the host operating system itself is determined by the isolation modes in use.

There are three main methods of setting the sandbox location for an application:

  • The SandboxPath parameter in package.ini
  • A Thinstall folder in the same directory as the ThinApp application’s .exe file(s)
  • The value of the %THINSTALL_SANDBOX_DIR% environment variable on the host operating system

If none of these methods have been used, the default location of the application sandbox is %appdata%\thinstall\application, where application is replaced by the name of the application as configured in its package.ini.

 

Isolation Modes

Isolation modes apply to individual directories, subdirectories, and registry locations. The three isolation modes are:
  • Merged – This isolation mode causes all modifications made by the application to be made to the host operating system. (If a file already exists in the virtual OS, changes are made in the sandbox.)
  • WriteCopy – This isolation mode causes all modifications made by the application to be made to the application’s sandbox.
  • Full – This isolation mode causes all modifications made by the application to be made to the application’s sandbox. In addition, when the application is looking for a file or registry value, it does not query the host operating system for this data.

Application Data Precedence

When an application is looking for a file or registry value, it queries these locations in this order:

  1. The application’s sandbox. Any modifications made by the application when either WriteCopy or Full isolation mode was used.
  2. The virtual operating system. This is the set of files and registry entries that were stored in the project source directory on the machine that ran ThinApp’s Setup/Capture wizard. This is all contained in its .exe or .dat file.
  3. The native operating system. Any file or registry entry that actually exists on the host operating system.

Note: When something is found, ThinApp immediately stops querying for it in any other location.

 

Summary Of Isolation Modes And Data Precedence

Isolation mode

Data is read from (until found)

Data is written to

Merged
Sandbox
Virtual OS
Native OS
Native OS
(If already existing in the Virtual OS, changes go to the Sandbox.)
WriteCopy
Sandbox
Virtual OS
Native OS
Sandbox
Full
Sandbox
Virtual OS
Sandbox