PRB: FindExecutable() Truncates Result at First Space in LFN

• Microsoft Win32 Application Programming Interface included with:

      - Microsoft Windows 95
      - Microsoft Windows NT versions 3.1, 3.5, 3.51
  

SYMPTOMS

The FindExecutable function is supposed to retrieve the fully qualified path to the executable (.exe) file associated with the specified file name. For example, the following call to FindExecutable() should return the path to Winword.exe:

   FindExecutable ("C:\\README.DOC", NULL, szBuffer);

However, when you use FindExecutable() on a file whose associated application is in a directory that has a long file name (LFN) that includes a space, the function truncates the string up at the first space. Going back to the previous code example, if Winword.exe is located in the C:\Program Files\My Accessories directory, the function incorrectly returns the truncated string C:\Program instead of the following expected string:

   C:\Program Files\My Accessories\Winword.Exe

CAUSE

File associations are stored in the registry under HKEY_CLASS_ROOT, where the executable name is actually stored under the key

   HKEY_CLASSES_ROOT\<file Type>\shell\open\command = <Name of Executable>

In the example, the path to WinWord.Exe should be stored in the registry as:

   HKEY_CLASSES_ROOT\Word.Document.6\shell\open\command =
    "C:\Program Files\My Accessories\Winword.Exe" /n

Note that this problem does not occur when the short path name is stored in the registry, instead of the long file name. Again, taking the same example to WinWord.exe, this should not be a problem if the short path name "C:\Progra~1\MYACCE~1\WINWORD.EXE" is stored in the registry instead of the LFN version.

WORKAROUND

In some situations, applications do not have control over what gets stored in the registry. It may be the associated application's setup program that wrote the incorrect LFN string (without quotation marks) to the registry. Any application that would then call FindExecutable() on this associated application will run into this problem.

One workaround to this problem might be to parse the string returned and replace the \0 character with a space. Stepping through a debugger, after FindExecutable() returns, you will quickly find that although the space has been replaced with the NULL character (\0), the rest of the string is left intact, so simply reverting the \0 character back to a space gives the expected string.

STATUS

This behavior is by design.