Short Pathnames
Previous  Top  Next

What are short pathnames, and why are they important?

Short pathnames are DOS 8.3 compatible names that map into their long pathname equivalents. For example C:\PROGR~1 is the short pathname version of C:\Program Files.
Short pathnames are important for most applications for several reasons:

· Short pathnames eliminate spaces  
Short pathnames eliminate spaces from paths which prevents some compatibility and security issues. For example, when executing the command "C:\Program Files\Microsoft Office\OFFICE11\winword.exe c:\Myfile.doc" using ShellExecute, Windows will actually try a number of possible commands to see if they are valid:  
c:\Program.exe "Files\Microsoft Office\OFFICE11\winword.exe c:\Myfile.doc"  
c:\Program Files\Microsoft.exe "Office\OFFICE11\winword.exe c:\Myfile.doc"  
c:\Program Files\Microsoft.exe Office\OFFICE11\winword.exe "c:\Myfile.doc"  
If a user creates the file c:\Program.exe on a PC, it could break office and also represents a security threat.  
· Short pathnames allow compatibility with legacy applications  
16 bit applications cannot support filename paths other than 8.3 style. When windows runs 16bit applications, it will provide applications with the short pathname version for all filenames. This typically does not come into play for most people, but was one of the primary reasons for the original conception of short pathnames.  
· Short pathnames work-around Windows API path length limitations  
Many Windows API functions have limitations on the maximum string length they can handle for paths. For example on Windows XP SP1, the ShellExecute API command cannot handle a string length longer than 128 characters. Often the registry is used to store a value that look like "Command + Parameters" like this entry for Office 2003:  

   DefaultValue = C:\PROGRA~1\MICROS~3\OFFICE11\OIS.EXE /shellEdit "%1"  
If the Exe filename plus the parameter is greater than 128 characters, the command will fail on XP SP1 (Microsoft extended the length for ShellExecute in SP2). Considering the user is likely to use a filename from their "My Documents" folder, and the filename may be significantly long - if you don't use short pathnames there is a very high chance of failure.  
For example, this command exceeds 128 characters (168 chars):  
   C:\Program Files\Microsoft Office\OFFICE11\winword.exe c:\documents and settings\Greogory Appleblaught\My Documents\Draft 34 April 6 2006 Master License Agreement.doc  
The same path is much smaller using short pathnames (85 characters):  
C:\Progra~1\Micros~3\OFFICE11\winword.exe c:\docume~1\Greogo~1\MyDocu~1\Draft3~1.doc  
The use of Short pathnames in the registry is very common, for example Office installs hundrerds of short pathname references in the registry. Below you can see a few examples from an Office 2003 install.

Out of process COM 
   C:\PROGRA~1\MICROS~3\OFFICE11\GRAPH.EXE /automation  
In process COM  
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults\Provider\Microsoft Exchange Cryptographic Provider v1.0  
Intelligent Search  
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Intelligent Search\Schema\1.0\XML\MSUSP  
Interenet Explorer plugins  
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Extensions\{92780B25-18CC-41C8-B9BE-3C9C571A8263}  
Location of shared DLLs  
Error reporting and crash handling     

What are the issues with short pathnames and application deployment and migration?

Short pathnames are not consistent across PCs and are also highly dependent on installation order. For example, installing Microsoft Office after installing Microsoft Visual Studio can create identical short pathnames which refer to different location than when installing Microsoft Visual Studio and the Microsoft Office:

installing Microsoft Office and then Microsoft Visual Studio generates:
c:\progra~1\micros~1 and c:\progra~1\micros~2

c:\progra~1\micros~1 = c:\program files\Microsoft Office
c:\progra~1\micros~2 = c:\program files\Microsoft Visual Studio

installing Microsoft Visual Studio and then Microsoft Office also generates the same two paths which refere to different locations:
c:\progra~1\micros~1 and c:\progra~1\micros~2

c:\progra~1\micros~1 = c:\program files\Microsoft Office
c:\progra~1\micros~2 = c:\program files\Microsoft Visual Studio

When capturing a snapshot of an application's install, it will write a number of short pathname values to the registry as described above. When moving the application to a different PC or installing additional applications on the same PC may effect the short pathname values that the operating system provides from the underlying operating system. Virtualization solutions that are based on filter drivers do not have ability to control short pathname values because they are generated by the windows filesystem and as a result a capture on one PC has a good chance of failing when moved to another PC or when executed some time later on the same PC when other applications have been installed. Common areas of failure that occur when proper short pathname support is not available include:

· In-process and out-of-process COM failure.  
The application tries to create COM objects and fails because the registry values point to the in-process or out-of-process COM server no longer point to the correct location.  
· MSI is executed to reinstall the application even though it was fully installed.  
msi.dll performs an integrity check for all msi installed components requested by the application. If msi.dll notices a DLL or data file is not located at the same location as it was originally installed to, it will kick off a reinstall procedure to try to correct the problem.  
· Failure to execute child processes  
Many child process applications are executed using registry values that point to short pathnames. If the values do not point to the correct location, the child process will fail to launch. This will often render the application unusable.  
· Application fails to load  
Applications may crash or fail to load because the cannot locate there installation path or shared DLL paths using registry data.  
· Application complains of missing data files  
The application may display error messages relating to missing files because it can no longer locate a file using a short pathname pointer from the registry.  

How Thinstall solves short pathname Migration

Thinstall uses a combination of dynamic registry data expansion and virtual short pathnames to enable applications to instantly migrate from one PC to another. When an application writes a value to the registry, Thinstall will scan the data to see if it references a short pathname or shell folder location. If it does, Thinstall will store it internally in macro format which encodes both the shell folder location and the long pathname value for a short pathname. At runtime, when the application queries the same registry value it will receive the original value it wrote to the registry. If the application moves to a different PC where the short pathnames are different it will obtain an automatically adjusted value.

For example, if you look at HKEY_LOCAL_MACHINE.txt for a capture of Microsoft Office you'll see some entries that look like this:

isolation_full HKEY_LOCAL_MACHINE\Software\Classes\CLSID\{03B54468-0899-4233-8689-623FFFC295EE}\InprocServer32
REG_SZ~%ProgramFilesDir~0032\Common Files\Microsoft Shared\Smart Tag\IETAG.DLL#2300

In this case the registry value is encoded to expand to the shell folder location "c:\program files" plus "\common files\microsoft shared\smart tag\ietag.dll" like the following expression:

GetShortPathName(ExpandMacro("%ProgramFilesDir%") + "\Common Files\microsoft shared\smart tag\ietag.dll")

Because Thinstall 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 there is no startup overhead time for applications with large registries.

Preventing conflicts when Isolation is used

In a virtual environment where the application is isolated from the PC, the normal file system will not be aware of short pathnames that a virtualized application wants to use. For example consider the following senerio:

A desktop PC has Microsoft Office Installed installed natively (no virtualization)
In this case Microsoft Office occupies the short pathname c:\progra~1\micros~1

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 pathname other than c:\progra~1\micros~1 since this is in use. The application must reserve the short pathname c:\progra~1\micros~2 when short pathname is allocated by the Windows filesystem. A problem arises if a 3rd "Microsoft" application is installed while Visual Studio is running, will it get microso~3 or microso~2? In the later case, it will conflict with the virtual application and the virtual application may fail.

Thinstall does not use filter drivers and does not depend on the Windows file system for the allocation of short pathnames. Thinstall prevents conflicts between short pathnames between virtual applications and system applcations by using it's own short namespace which will not collide with system applications. Since each virtual application is isolated from all other virtual applications there is no problem with having 2 virtual application using the same short pathnames internally. In the screen shot below you can see Thinstall uses a different name space than Windows for short pathnames when the system does not have the paths already created. You can see this in action by running a virtualized cmd.exe and use "dir /x" to list short pathnames. The three directories below do not follow the normal Windows convention of ABCDEF~1.


Result: Install to default location, migrate seemlessly
Other virtualization solutions require you to install applications to seperate drive letters using 8.3 filenames in order to resolve the various short pathname issues described above. Because many applications will not let you specify an alternate installation path or will not run correctly when installed to a non-default location, this approach can only be used in limited situations. When using Thinstall's Setup Capture to create Thinstalled applications, you can install applications using their default location without concern for short pathnames.