VMware THIN4-CL-C Getting Started Guide - Page 14

Introduction to VMware ThinApp When using VMware ThinApp, administrators do not need to consider how their system‐wide security policies are affected. VMware ThinApp can be deployed in conjunction with central IT group policies or separately in the case of smaller development groups. Developer groups can use the code components and frameworks of their choice without requiring security policy changes by their IT organization. Improved System Stability in User Mode System failures can be hard to diagnose without significant time and resources. Most system failures are caused by third‐party device drivers. Every instruction running in kernel mode represents a risk of system failure. Often failures are caused by thread deadlocks that only occur under rare circumstances and when combined with other products. Kernel‐mode applications have no protection from system failure or leaked resources. A kernel‐mode system failure is often caused by a deadlocked thread, so that the machine appears to be frozen or performs badly for no apparent reason. User mode code can never directly cause a system failure and can be easily stopped with a task manager if it causes the system to freeze. There is no other impact on the system. Windows automatically cleans up after a failure by closing open file handles, freeing allocated memory, and discarding created resources. User mode enables you to run applications directly from locked down accounts without preinstalling a device driver or granting the user elevated security privileges. Because ThinApp has no device drivers, it enables deployment of applications with zero footprint on desktop PCs. Applications can run from network shares with no preinstallation requirements. Side-By-Side (SxS) VMware ThinApp supports Side‐by‐side (SxS). SxS is an operating system feature supported by Windows XP, Windows 2003, and Windows Vista. SxS is required to deploy most current software products including Microsoft Office 2007, Adobe Reader 8, and .NET 2.0/3.0. With SxS technology, applications can install DLLs to version‐specific directories. This informs Windows which version of the DLL should be used when that DLL is loaded. For example, Microsoft Office 2007 installs MFC80 (8.0.50727.42) to the following path: %SystemRoot%\WinSxS\x86_Microsoft.VC80.MFC_1fc8b3b9a1e18e3b_8.0.50727.42_x-ww_dec6ddd2\mfc80.dll The path contains information about the DLL version. The only way to place files at this location is by using MSI installer technology. An installed SxS DLL is installed in different locations on Windows XP and Windows Vista. Because users might migrate their existing Windows XP installations to Vista, the upgrade process automatically moves the DLLs to their new location on Vista. Windows operating systems that have SxS look for an application's manifest information to determine which version to load from SxS. A manifest is an XML description of all the SxS DLLs that can be loaded by an application. The manifest also states which version of those DLLs to use. The manifest can be embedded in the application executable or DLL in the file as a resource. The manifest can also be stored separately on the file system as a .manifest file. The manifest file for app.exe is called app.exe.manifest. The manifest resolution algorithm provides search capabilities based on the user's language (for example, French and German versions are available). SxS DLLs have a force upgrade mechanism implemented as separate security policy files (also XML files). This mechanism enables Microsoft to override version number requests by applications if a security hole is discovered in a shared library. For example, an application manifest might request version 1.0.0.0 of a given DLL, but Microsoft can provide a policy file update that redirects all requests of version 1.0.0.0 to 1.0.0.5. If the application normally installs DLLs to c:\windows\winsxs\..., this is reflected in the capture and appears in your project under %systemroot%\winsxs\.... 14 VMware, Inc.