Since it cannot be mentioned too many times, ThinApp is agentless. Nothing needs to be installed on the client in order to run and use a ThinApped application. The ThinApp runtime is built into each one of the ThinApp packages you create. ThinApp does not create conflicts between different versions of ThinApp runtimes, so you can run packages built using different ThinApp versions on one single machine.
The ThinApp runtime manages file and registry access within the virtual environment. With the help of isolation modes you can decide what may or may not be modified on the native operating system. The ThinApp runtime loads processes and manages memory. Because it is the ThinApp runtime that launches a process, the runtime now monitors all API calls made by the process. The runtime is also able to intercept the API calls and manipulate both the request and reply. This is referred to as hooking the API calls. The ThinApp runtime hooks hundreds of Win32 APIs in order to create the virtual environment. Let's say an application tries to open a file. The ThinApp runtime sees this request, hooks it, and is now capable of passing a virtualized file to the application, instead of serving the native file to the application. The ThinApp runtime does not hook all possible Windows APIs, only the ones needed to present a virtual environment to the application package. API calls to hardware such as graphical drivers are not hooked.
A ThinApp package contains not only the ThinApp runtime, but also includes a virtualized registry and filesystem. You as a packager decide the content of the virtual environment during packaging. The virtual environment built into the package is called the read-only version of the virtual environment. The end user cannot modify the content within the package. Only you as a packager can change the content.
Changes made by either the user or the application itself are often stored in the sandbox. The sandbox content is a part of the whole virtual environment known to the application.
The view of the environment of a package is a merge between the physical and the virtualized. In the previous screenshot, Mozilla Firefox sees the content of native C:\Program Files as well as the virtualized folder called Mozilla Firefox. The Mozilla Firefox folder is not available to the operating system (Explorer window).
When the virtualized application is launched, the virtual environment is initiated by the ThinApp runtime and presented to the executing process. The application believes it is locally installed on the machine. The packaging process of ThinApp does not alter the application's files in any way. The ThinApp runtime loads the processes and by launching it, the ThinApp runtime can hook into the API calls made by the processes and present the virtual environment.