In order to have a meaningful discussion about ThinApp, we need to agree on some common vocabulary. I prefer to give you this vocabulary earlier in the book rather than later. If you have already used ThinApp, most of this will already be known. If you are new to ThinApp, don't worry, as we will cover all of it in more detail as the book progresses.
This is the whole process of capturing an application. You can run Setup Capture, install your application, and save the capture into a project folder. The capture process analyzes all changes made to your capture machine and stores those into a project folder. These changes are what will become the virtual environment and make the captured application believe it is locally installed on the target machine.
This is the machine on which you run the capture process. Most of the time it's a virtual machine since that allows easy reversion to different machine states (snapshots). After successfully capturing an application, you will revert to a clean state before you capture a new application.
This is the outcome of your capturing process. Now the real work as a packager begins. It's the project folder that contains the virtualized environment such as files and registry keys recorded during your capturing process.
When you compile your project folder, the outcome will be the package. The package is what your users consume in order to execute the captured application. The package will normally be found in the bin folder within your project folder. A package can be one single file or multiple files, one being the data container and others being entry points.
The data container is the file containing your compiled project folder. It's the container for the whole virtual environment and the ThinApp runtime.
Entry points are the doorways for the user to access the virtualized application. An entry point specifies what will be executed in the virtualized environment of your data container. The target of your entry point may or may not be virtualized. It is possible to have an entry point for a Java Runtime package launching your locally installed Internet Explorer. Internet Explorer would see the virtualized environment and therefore use the version of Java packaged. An entry point can also be a data container. Otherwise, if it's only an entry point, the data container must be located in the same folder as the entry point. An entry point can be used to any data container. The entry point simply searches for the specified data container's name and will happily use any data container. An entry point contains registration information such as icon, file types, object types, protocols and where to create shortcuts.
The building process is the
process of taking the content of your project folder and compiling it into a virtual environment. This process can be issued from within ThinApp's capturing tool, Setup Capture, or from within your project folder by launching the build.bat batch file. Every time you change the content of your project folder, you'll have to recompile it in order for the changes to be applied to the package.
This is any machine you can use to compile your project. It may or may not be your capture machine. You do not have to use a certain operating system or even a clean machine in order to compile your package. Any machine should do the trick. The build machine must have access to the ThinApp utilities folder and your project folder in order to successfully compile your project.
This is the folder
created during the installation of VMware ThinApp. Most of the time it's found in C:\Program Files\VMware\VMware ThinApp. Since ThinApp utilities are virtualized, you can move this folder to any location. I personally store the folder on a network share for easy access from all my different capture machines.
This package embedded runtime allows the virtual environment to be created. The ThinApp runtime loads the virtualized application's processes and DLLs. It hooks Windows APIs in order to present a virtualized environment to the virtualized application.
This is the virtual environment, filesystem, and registry, compiled into the ThinApp package. Since the package is in a compiled format, no regular end user can open this file and modify its content.
This is what we call the data stored in the sandbox. The sandbox is where ThinApp stores changes made to the environment by the virtualized application or the end user. Deleting the sandbox will revert the package to its read-only data state.
These are much like system variables in a Windows operating system, but these are ThinApp-specific variables. Some folder macros share the same name as Windows variables such as %AppData% pointing to the users' roaming profile. But others are different, for example %ProgramFilesDir% represents the system variable %ProgramFiles%. When you use VBScripts within your packages, you must understand that there is a difference between folder macros and system variables. The use of folder macros allows package portability. When you launch a package on an English OS, your %ProgramFilesDir% will be C:\Program Files, while on a German OS it is the same folder macro pointing to C:\Programme. This way, the application you virtualized will find its installation folder where it expects to find it, no matter what language of OS it's running on. You can find a list of all folder macros in References.