Dynamic-Link Library Redirection Explained

Dec 25, 2000

Windows 2000
Recommended: Delphi 5 (any edition)

Has your application ever broken on the customer's computer because a rogue application overwrote a DLL your application needs? If so, you should advice your customer to switch to Windows 2000. Although not perfect, Windows 2000 provides an efficient solution for avoiding the common "DLL hell", called DLL redirection (for more information, visit the MSDN Library).

When your application uses LoadLibrary or LoadLibraryEx to load a DLL at run-time, Windows uses a common, documented algorithm for locating the DLL. However, most applications use an absolute path for locating custom DLLs. For example:

C:\Program Files\Common Files\ImportantDLL.dll

In this case, Windows doesn't look for alternative paths. But, what happens if ImportandDLL gets replaced by a wrong version? Anything can! Surely, you could store each DLL in your application's own directory, but this would waste disk space on the customer's hard drive.

Redirecting DLL loads

Windows 2000 provides a partial solution to the before-mentioned problem. Your application doesn't require any modifications, and it can continue to access DLLs in common locations. However, the Windows 2000 solution comes into play after problems occur.

When your application starts, Windows 2000 tries to locate a file named appname.local (for instance, if you application is named SuperApp.exe, Windows looks for SuperApp.exe.local) in the same directory where the application's EXE file is.

If this file exists (it doesn't need to have any content), LoadLibrary(Ex) calls first look the application's main directory (the directory where the .exe resides). That is, if you call LoadLibrary with the above path and the .local file exists, Windows 2000 will look for ImportantDLL.dll in the main directory.

Why this is useful?

Consider the advantage when a customer calls your company's technical support department. When an application problem is pinpointed to an incorrect DLL, and simply reverting to the old version would break another application, your tech support can simply send in the old DLL and the .local file.

When these files are placed in the original directory and the application is restarted, the problem is solved. The workings of Windows 2000 and the DLL redirection can be easily tested with a simple test application (239 kB). This application is able to load a DLL, and call an Info function in it, which displays the original name of the file.

The code to load the DLL is as follows:

procedure TForm1.Button2Click(Sender: TObject);
Type TInfoProc = Function : PChar;
Var
  IP : TInfoProc;
  H  : THandle;

begin
  H := LoadLibrary(PChar(Edit1.Text));
  If (H = 0) Then Begin
    ShowMessage(SysErrorMessage(GetLastError));
    Exit;
  End;
  @IP := GetProcAddress(H,'Info');
  ShowMessage(IP);
  FreeLibrary(H);
end;

By renaming the DLL "B" to a similar name than the "A" DLL, you can test the .local file. Easy.

* * *

Do you need help solving your development problems on the Windows 2000 platform? Let us help!