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

Introduction to VMware ThinApp Solving the Short Path Name Migration Problem ThinApp uses a combination of dynamic registry data expansion and virtual short path names to enable applications to instantly migrate from one PC to another. When an application writes a value to the registry, ThinApp scans the data for references to a short path name or shell folder location. If the application does this, VMware ThinApp stores the value internally in macro format that encodes both the shell folder location as well as the long path name value for a short path name. At runtime, when an application queries the same registry value, it receives the original value it wrote to the registry. If the application moves to a different PC where the short path names are different, it obtains an automatically adjusted value. For example, if you look at HKEY_LOCAL_MACHINE.txt for a capture of Microsoft Office, you see some entries similar to the following: isolation_full HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{03B54468-0899-42338689-623FFFC295EE}\InprocServer32 Value= REG_SZ~%ProgramFilesDir~0032\Common Files\Microsoft Shared\Smart Tag\IETAG.DLL#2300 Value=ThreadingModel REG_SZ~Apartment#2300 In this case, the registry value is encoded to expand to the shell folder location c:\Program Files and \common files\microsoft shared\smart tag\ietag.dll as in the following expression: GetShortPathName(ExpandMacro("%ProgramFilesDir%") + "\Common Files\microsoft shared\smart tag\ietag.dll") Because ThinApp performs this macro expansion and collapse for every registry operation, it has been highly optimized to require very little CPU overhead. The expansion and collapse occurs dynamically at runtime, so no startup overhead time for applications with large registries occurs. Preventing Conflicts When Isolation Is Used In a virtual environment where an application is isolated from a PC, the normal file system is not aware of short path names that a virtualized application needs to use (for example, when a desktop PC has Microsoft Office installed natively). In this case, Microsoft Office occupies the short path name c:\progra~1\micros~1. Suppose that, on this same desktop, a virtual version of Microsoft Visual Studio application begins running. In this case, Visual Studio needs to use a different short path name other than c:\progra~1\micros~1 because this name is already in use. The application must reserve the short path name c:\progra~1\micros~2 when the short path name is allocated by the Windows file system. A problem arises if a third Microsoft application is installed while Visual Studio is running. It is uncertain if the process will receive a micros~3 or micros~2 short path name. In the latter case, it conflicts with the virtual application and the virtual application might fail. ThinApp does not use filter drivers and does not depend on the Windows file system for the allocation of short path names. ThinApp prevents conflicts between short path names between virtual applications and system applications by using its own short namespace that does not collide with system applications. Because each virtual application is isolated from all other virtual applications, you can have two virtual applications using the same short path names internally. ThinApp uses a different namespace than Windows for short path names when the system does not have the paths already created. You can see this in action by running a packaged cmd.exe and use dir /x to list short path names. When you use ThinApp Setup Capture to capture applications, you can install captured applications by launching them from their default location without concern for short path names. 18 VMware, Inc.