Getting Started
Previous  Top  Next

This walk-thru assumes you have installed Thinstall to your development PC using the .MSI provided in your online account.

1. Setup a clean PC if you do not already have one.
Why should I use a clean PC?  
Installing VM Server  

2. Share your ThinstalVS directory and launch SetupCapture on a clean PC
We recommend launching Setup Capture directly from a network share to ensure no changes are made to the local PC except by the installed application. In order to create a full capture of an application you should have available a clean Windows system for the lowest platform you need to support. For example, use Windows 2000 if you plan to support 2k,XP,2k3, and Vista.


3. Use default options and select "Pre-install Scan"
On a fast clean PC, the scan process should take ~10 seconds for Windows XP.

4. When the scan finishes, install your target application.
After installing your application you may also want to configure it as you want it to appear when the resulting Thinstalled application is first executed by a new user.

If the application does not have an installer, you can manually copy the application files to the capture machine and add desktop or shortmenu shortcuts to EXE files you want to generate Thinstall EXEs for during the build process. Setup capture will automatically detect all the changes made to the guest machine including installation of 3rd party libraries, COM registrations, and registry edits.

4. After the application has been installed and configured, click Post-install Scan

6. Confirm Location to save project and Click Save Results >>
Thinstall will suggest a name for the project. If the application installed multiple components, you may need to adjust the suggested name.


7. Switch to dev PC with ThinstallVS installed, and execute build.bat
This will execute the virtual registry compiler, virtual filesystem packager, and runtime linker to produce one or more EXE files in the bin directory under your project. If you installed ThinstallVS to a location other c:\Program Files\ThinstallVS, you need to set the environment variable THINSTALL_BIN before executing the build.bat file. ThinstallVS can be run from a shared network location so it does not need to installed locally.

Note: Thinstall selects one "primary" EXE to host the Thinstall runtime plus application registry data and files. The other EXE files are simply "Shortcuts" to the main EXE and can be deleted prior to distribution to users if they are not needed. EXEs are selected based on which shortcuts were installed by the application during install, so you can delete unimportant shortcuts before completing the post-install setupcapture scan on capture machine. If you want a different primary EXE after SetupCapture has completed, you can edit the package.ini file. Shortcut EXEs cannot be run unless the "primary" EXE is located in the same directory. Shortcut and the primary EXE will share a common virtual registry and filesystem and can interact with each other.

Editing package.ini
For example, with Acrobat reader we can make AcroRd32.exe the only EXE by editing:

Before edit:  
Source=%ProgramFilesDir%\Common Files\Adobe\ESD\AdobeDownloadManager.exe  
Source=%ProgramFilesDir%\Adobe\Acrobat 7.0\Reader\AcroRd32.exe  
Source=%ProgramFilesDir%\Adobe\Acrobat 7.0\Reader\reader_sl.exe  
After edit:  

Source=%ProgramFilesDir%\Adobe\Acrobat 7.0\Reader\AcroRd32.exe  

At this point you have a virtualized application which can be run directly from a network share on restricted accounts without installation or modification to local PCs. The Thinstalled EXE is read-only and never changes, so it can be placed in a central location where it is shared by multiple users. Thinstall supports files of unlimited size and provides transparent streaming capabilities so a 2 terra-byte file can be launched over the LAN in seconds, only the data required to launch the application is pulled across the network. Windows 2k and XP have a known issue where they will not display icons in the Explorer shell for very large EXE files, the exact size depends on the local PC, but typically around 500MB-1GB. Because shortcut EXEs are always very small, they will never encounter this problem, only the primary EXE and a dummy primary EXE can be used as a work-around for large packages.

Controlling the location of the Sandbox

The sandbox is the directory where all changes made by the application will be stored. The next time the user executes the application, those changes will be remembered from the sandbox. By deleting the sandbox directory, you can instantly revert the application back to it's captured state.

By default the sandbox is located in the users "%AppData%" directory, i.e.:
c:\documents and settings\username\Application Data\Thinstall

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 in on any machine and retain their application settings. Thinstall transparently remaps registry and file data while the application is running to enable shared application profile information to instantly migrate to different OSes. For example, if the application registers DLLs to c:\winnt\system32 while running on w2k the user can quit the application and login on an XP box. On the XP box, the files will automatically apprear to exist at c:\windows\system32 and all related registry keys will automatically point to c:\windows\system32. On Windows Vista, Thinstall automatically moves Windows SXS (Side by Side) 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. Thinstall provides SXS support for applications running on Windows 2000 even though the underlying operating system does not, this enables most applications captured on XP to run on w2k without changes.

Note: Only one computer may be actively using a shared sandbox simultaneously. If a sandbox is already in use by another computer Thinstall will display a warning and create a new sandbox to allow the user to continue working until the previous copy closes.

Portable Applications
To make an application portable so that it can be executed from a USB Flash device, IPod, etc. the sandbox should operate in "local" mode. In this mode, the sandbox is in a subdirectory relative to the EXE. This mode is not recommend for shared environments like Terminal Server unless each user has their own copy of the application because sandboxes are not user specific but instead become location specific. To cause an application to run with a local sandbox, simply create a directory called "Thinstall" in the same directory as your Thinstalled application. You can also move the Thinstall directory from %AppData% to the application directory to take existing application settings and make them operate in local mode.