DLLs can be unique to a single program, but system wide capabilities are provided by shared copies of DLLs operating on different data for different calling programs. In principle, this saves a little disk space and some memory space, In actuality, addressing conflicts may prevent DLLs from being shared in memory in which case, multiple copies are provided by the OS as required.
Unfortunately (but unsurprisingly) the shared aspect of DLLs leads to some problems. DLLs sometimes need repairs or improvements. Therefore, there are various versions of some DLLs. Is is impractical for software writers to test their software with all versions of the DLLs it uses and impossible for DLL authors to test their DLLs with all the software that might use them. Software is sometimes incompatible with some versions of DLLs. If a program installation includes the DLL versions it needs, and if those DLLs are actually used, it will probably work after installation. But other programs that used to work may not because the new DLL is incompatible. Also, if two programs use internal DLLs that happen to have the same name, Windows does not know that the DLLs are different and will try to load only the first one found. This situation -- Program A quits working when B is installed or is invoked first -- has come to be known as "DLL Hell".
The practice of overwriting Windows DLLs has largely been abandoned in newer software. That decreases the chances of killing other software when new software is installed, but increases the chances that the new software will not work. For the truly concerned, A DLL analysis package called DUPS is available from Microsoft. Search the knowledge Base for Q247957.
Windows 2000 and Windows 98SE contain some provisions to control DLL usage. In Windows 2000 there are Registry keys which indicate which DLLs are to be considered for sharing. Windows 2000 also automatically restores any of 2800(!) "protected DLLs" deleted by installation routines. This is called "Windows File Protection". The good news is that Office -- a traditional cause of configuration problems -- is not one of the trusted programs allowed to do maintenance replacement of the protected DLLs.
Windows 2000 has a defined search order for DLLs (possibly) starting with the invoking program's local directory. Microsoft looks in the Registry rather than the local directory to identify the "Private DLLs" [I doubt this is the best idea they've had recently.] There are different loading rules for "Known DLLs" identified in the Registry than for private DLLs. Private DLLs are also known as side-by-side DLLs since they will run side by side with system versions of DLLs. The DLL search rules are somewhat complex [the adjective "byzantine" comes to mind] being different for 16 and 32 bit DLLs as well as for implicitly and explicitly loaded DLLs. There are a small number of DLLs like USER.DLL that can not be overridden with a Private DLL. It is anticipated that some of these will be made privatizable in future OS releases.
The Unix equivalent of a DLL is a shared library. Unix shared libraries are generally used by routines written and tested together. "DLL" conflicts are less of a problem in Unix/Linux than in Windows.
Microsoft is promising to address many of its DLL issues in a major desktop release in late 2004 codenamed "Longhorn" and Windows Server 2003. The technology is called "xcopy deployment" or "DLL strong binding".
Return To Index Copyright 1994-2002 by Donald Kenney.