What is View Sandbox?

Introduction to the Sandbox

The sandbox holds runtime modifications that applications make as they are running. The original executable that you built never changes, so it can be placed in a shared folder with read-only access. The name of a sandbox (SANDBOXNAME) is specified in the package.ini file prior to building your package.

Under normal circumstances, the sandbox is stored under %AppData%\Thinapp\SANDBOXNAME. On Windows XP this path is C:\Documents and Settings\USERNAME\Application Data\Thinapp\SANDBOXNAME.

During startup, ThinApp searches for an existing sandbox in the following locations in the order listed below. If a sandbox already exists, ThinApp uses the existing sandbox rather than creating a new one.

Controlling the Location of the Sandbox 
The sandbox is the directory where all changes made by the application are stored. The next time the user executes the application, those changes are remembered from the sandbox. By deleting the sandbox directory, you can instantly revert the application back to its captured state.

By default the sandbox is located in the users %AppData% directory:
c:\documents and settings\username\Application Data\Thinapp

Using Active Directory, the user’s %AppData% is often mapped to a shared network drive to allow for easy backups. When this is the case, users can log into any machine and retain their application settings.

ThinApp transparently remaps registry and file data while the application is running to enable shared application profile information to instantly migrate to different operating systems. For example, if the application registers DLLs to c:\winnt\system32 while running on Windows 2000, the user can quit the application and login on a Windows XP machine. On the Windows XP machine, the files automatically appear to exist at c:\windows\system32 and all related registry keys automatically point to c:\windows\system32.

On Windows Vista, ThinApp automatically moves Windows SxS DLLs and policy information to match Vista versus XP file path styles. This functionally allows most applications to instantly migrate to newer or older operating systems.

ThinApp provides SxS support for applications running on Windows 2000 even though the underlying operating system does not. This enables most applications captured on Windows XP to run on Windows 2000 without changes.

Important Note; Only one computer can be actively using a shared sandbox. If a sandbox is already in use by another computer, ThinApp displays a warning and creates a new sandbox to allow you to continue working until the previous copy closes.

SandBox and Portable Applications
To make an application portable so that it can be executed from a USB Flash device, IPod, or other similar device, the sandbox must operate in local mode. In this mode, the sandbox is in a subdirectory relative to the executable. This mode is not recommended for shared environments like Terminal Server unless each user has his own copy of the application. Sandboxes are location-specific, not user-specific.

To set an application to run with a local sandbox, create a directory called Thinapp in the same directory as your captured application. You can also move the Thinapp directory from %AppData% to the application directory and make the existing application settings operate in local mode.

Sandbox Considerations when Upgrading an Application
When you release an upgrade to an application, you can control whether the user continues to use his or her previous settings by keeping the sandbox name consistent in your package.ini file. By deploying a new application version with a new sandbox name, each user creates a separate sandbox and starts with a new installation maintaining isolated settings. If you deploy the package with the same sandbox name, users keep their previous settings.

Reference: http://edwinfriesen.nl/content/?p=92