Application Specific Paths for DLL Loading

原文链接：http://www.codeguru.com/Cpp/W-P/dll/article.php/c99

Configuring workstations to handle shared DLLs is difficult. In manyorganizations, the PATH environment becomes a point of contention between project teams.Configuring a PATH specific to your application can solve the problems associated withusing a common search PATH, and eliminate many configuration errors in your application aswell. This article first describes the current methods of application configurationand the problems associated with them. Finally, the specific details of adding anapplication specific path in the registry are described. The solution is compatiblewith both NT and '95.

As many of you already know, and as the Visual C++ documentation illustrates, theoperating system will use the following algorithm for locating a DLL. (Load VisualC++ help on LoadLibrary()).

1. The directory where the executable module for the current process is located.
2. The current directory.
3. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
4. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
5. The directories listed in the PATH environment variable.

Now, imagine the following situation in which two applications (ONE.EXE and TWO.EXE)need to share a common DLL (COMMON.DLL). The applications install the files into thefollowing directories.

There are several ways to configure the machine using the above search algorithm.

1) Put all applications into a single directory

Hmm, one big directory. Sounds great until you need to remove one application,and can't figure out which files to delete. While your at it, why not just make onebig .EXE file?

2) Modify the current directory

Faced with the above problems, many programs were configured to be started with thecurrent directory pointing to the DLL. This is easily set in the short-cut whichstarts the application. While this gives each program control of the DLLs that itloads, it also has several side effects:

1. Any documents written will be written to the DLL location.
2. File Open dialogs start out in the DLL location.
3. Programmatically changing the current directory may cause future DLL loads to fail.
4. It's difficult to control current directory if one program invokes another.

3) Put common files into the Windows or System directory

Many applications store DLLs in the Windows or System directory. This creates amaintenance problem, particularly if the system files need to be replaced. Manyorganizations have begun locking down the Windows and System directories, in an effort toreduce maintenance costs.

4) Modify the PATH environment variable

Certainly the most straight forward approach is to have C:\Program Files\Common addedto the path. This was how things were done in the Win 3.1 days. There areseveral problems:

1. If the workstation includes several applications, the PATH becomes incredibly long.
2. The order in which directories appear on the path becomes important.
3. The system spends a great deal of time searching directories that are never used by the application.
4. The program cannot determine which location is used to load a DLL.
5. Installation programs require re-boots for the path changes to take effect.

Finally, Application Specific Paths!

Microsoft has offered a solution to all these problems. Each application can nowstore it own path the registry under the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\AppPaths

The use the application path, set a key for your application, using ONE.EXE from theexample above:

HKEY_LOCAL_MACHINE\...\CurrentVersion\App Paths\ONE.exe

Set the (Default) value to the full path of your executable, for example:

C:\Program Files\ONE\ONE.exe

Add a sub-key named Path, set it's value to the full path of the DLL, for example:

C:\Program Files\Common

With an App Path registry entry, the system will load DLLs in the following order.

1. The directories listed in the App Path registry key
2. The directory where the executable module for the current process is located.
3. The current directory.
4. The Windows system directory. The GetSystemDirectory function retrieves the path of this directory.
5. The Windows directory. The GetWindowsDirectory function retrieves the path of this directory.
6. The directories listed in the PATH environment variable.

Run REGEDIT to see examples of other applications, and how they setup their App Pathkeys.