Application Specific Paths for DLL Loading

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

As many of you already know, and as the Visual C++ documentation illustrates, the operating system will use the following algorithm for locating a DLL. (Load Visual C++ 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 the following directories.

Application 1 Application 2
C:\Program Files\ONE\ONE.exe C:\Program Files\TWO\TWO.exe
C:\Program Files\Common\COMMON.DLL C:\Program Files\Common\COMMON.DLL

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 one big .EXE file?

2) Modify the current directory

Faced with the above problems, many programs were configured to be started with the current directory pointing to the DLL. This is easily set in the short-cut which starts the application. While this gives each program control of the DLLs that it loads, 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 a maintenance problem, particularly if the system files need to be replaced. Many organizations have begun locking down the Windows and System directories, in an effort to reduce maintenance costs.

4) Modify the PATH environment variable

Certainly the most straight forward approach is to have C:\Program Files\Common added to the path. This was how things were done in the Win 3.1 days. There are several 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 now store it own path the registry under the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths

The use the application path, set a key for your application, using ONE.EXE from the example 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 Path keys.

History



Comments

  • I seem to get a different order for the algorithm

    Posted by Legacy on 09/25/2002 12:00am

    Originally posted by: lawrence

    on 98, NT, and 2K: App Path comes before the PATH environment variable and after GetWindowsDirectory.

    on XP: App Path is at the end after PATH environment variable.

    can anyone confirm?

    Reply
  • Does not work in the Debugger or from command line

    Posted by Legacy on 10/03/2000 12:00am

    Originally posted by: Scott Aron Bloom

    For non GUI based code, meaning code getting run from
    the command line (cmd.exe), this does not work. Any suggestions?

    Reply
  • Dll which implicitly loads another dll

    Posted by Legacy on 12/01/1999 12:00am

    Originally posted by: Dan Winkler

    I have a dll which is a plugin for an application. My problem is that even if I set the key in the registry (whether I add the path to the main applications entry or create a similar one for the plugin dll). When the application attempts to load the dll if fails because the dll can not load the other dll. The overall objective is to place the "helper" dll's and files in a subdirectory. Any Suggestions???

    • Did you find a solution for it ?

      Posted by Jonathan Beaubien on 08/22/2012 08:54am

      Did you find a solution to this ? I am making a Maya plug-in which uses their "modules" system, meaning that I put all the plug-in files in a remote folder instead of clogging the maya folders. It's easier to clean-up and manage. But Maya does not search in these folders for DLLs upon which the plug-in MLL depends on. The App Path solution seems nice, but the problem is that more than one version of Maya can be installed at the same time (in different folders) and I want different versions plug-in to work on multiple versions. For example, MyPlugin 2012 with Maya 2012 and MyPlugin 2013 with Maya 2013. And I cannot have two keys named "maya.exe".

      Reply
    Reply
Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • Live Event Date: October 29, 2014 @ 11:00 a.m. ET / 8:00 a.m. PT Are you interested in building a cognitive application using the power of IBM Watson? Need a platform that provides speed and ease for rapidly deploying this application? Join Chris Madison, Watson Solution Architect, as he walks through the process of building a Watson powered application on IBM Bluemix. Chris will talk about the new Watson Services just released on IBM bluemix, but more importantly he will do a step by step cognitive …

  • In this webinar, IDC featured speaker Steve Conway, Vice President of High Performance Computing, will present an update on the global x86 HPC cluster market. The presentation will include IDC's five-year forecast for the medium- to large-scale technical computing and data analysis emerging markets by systems, processors and application middleware. Cray's featured speaker, John Lee, Vice President of Cray Cluster Advanced Technology Systems, will present the new Cray® CS400™ cluster series based on …

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds