Book Image

VMware ThinApp 4.7 Essentials

By : Peter Bjork
Book Image

VMware ThinApp 4.7 Essentials

By: Peter Bjork

Overview of this book

VMware ThinApp 4.7 is an application virtualization and portable application creator which allows users to package conventional applications so that they are portable. "VMware ThinApp 4.7 Essentials" shows you how to deploy ThinApp packages in order to improve the portability, manageability and compatibility of applications by encapsulating them from the underlying operating system on which they are executed. Application virtualization improves the portability, manageability and compatibility of applications by encapsulating them from the underlying operating system on which they are executed. VMware ThinApp 4.7 is an application virtualization and portable application creator which allows users to package conventional applications so that they are portable. ThinApp eliminates application conflicts, reducing the need and cost of recoding and regression testing. In this book you will learn about how application virtualization works and how to deploy ThinApp packages. You will learn how to update and tweak ThinApp Projects before distribution. This book will then cover design and implementation considerations for future ThinApp projects.
Table of Contents (15 chapters)
VMware ThinApp 4.7 Essentials
About the Author
About the Reviewers

Common ThinApp vocabulary

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.

The capturing process

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.

The capture 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.

The project folder

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.

The package

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

The data container is the file containing your compiled project folder. It's the container for the whole virtual environment and the ThinApp runtime.

The entry point

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.

Compiling or building your ThinApp package

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.

The build machine

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.

The ThinApp utilities folder

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.

The ThinApp runtime

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.

Read-Only data

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.

Read and write data

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.

Folder macros

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.