DLL hell
DLL hell is an umbrella term for the complications that arise when working with dynamic-link libraries (DLLs) on older Microsoft Windows operating systems, particularly legacy 16-bit editions that all run in a single memory space. It manifests in various ways, often causing affected programs to fail to run correctly or at all. This phenomenon is the Windows-specific form of the general concept known as dependency hell.
Quick Facts
- Operating systems affected
- Pre-Windows NT versions of Microsoft operating systems, particularly legacy 16-bit editions
- Primary cause
- 16-bit operating systems did not restrict processes to their own memory space
- Introduced mitigation
- Windows File Protection (WFP) in Windows 2000
- Related concept
- Dependency hell
Facts from the source article.
Problems
DLLs are Microsoft's implementation of shared libraries, allowing common code to be bundled into a wrapper used by any application without loading multiple copies into memory. For example, GUI text editor code placed in a DLL can be used by all applications on the system without consuming extra memory. This contrasts with static libraries, which copy code directly into each application, causing every program to grow by the size of all libraries it uses.
The problem arises when the version of a DLL on the computer differs from the version used when the program was created. DLLs have no built-in mechanism for backward compatibility; even minor changes can render a DLL's internal structure so different that attempting to use it generally causes the application to crash. Static libraries avoid this because the version used to build the application is included inside it. A key reason for version incompatibility is the DLL file's structure: it contains a directory of individual methods and the types of data they take and return.
Even minor code changes can rearrange this directory, so an application calling a method it believes to be the 4th item might call an entirely different and incompatible routine, normally causing a crash. Common difficulties include conflicts between DLL versions, difficulty obtaining required DLLs, and having many unnecessary DLL copies.
Causes
DLL incompatibility has been caused by several factors. Memory constraints combined with a lack of separation of process memory space in 16-bit versions of Windows contributed significantly. There was a lack of enforced standard versioning, naming, and file-system location schemata for DLLs, as well as a lack of an enforced standard method for software installation and removal. No centralized authoritative support existed for DLL application binary interface management and safeguards, allowing incompatible DLLs with the same file name and internal version numbers to be released.
Oversimplified management tools prevented identification of changed or problematic DLLs. Developers broke backward compatibility of functions in shared modules, and Microsoft released out-of-band updates to operating-system runtime components. Earlier versions of Windows could not run side-by-side conflicting versions of the same library. Reliance on the current directory or %PATH% environment variable to find dependent DLLs, rather than loading them from an explicitly configured directory, also caused issues.
Developers sometimes reused ClassIDs from sample applications for COM interfaces instead of generating their own new GUIDs.
Solutions
Over the years, different approaches have helped reduce or fix various types of DLL hell. One straightforward fix is to statically link all libraries, meaning the program includes its own copy of the required library instead of relying on a system DLL with a matching name. This approach, common in C and C++ programs that use libraries like the Microsoft Foundation Class Library, removes the need for DLLs altogether. However, it defeats the main reason for using DLLs—sharing library code between programs to save memory—and leads to bloated software where the same code is duplicated across multiple applications.
It also makes it harder to deploy security updates or newer versions of dependent software. The problem of DLL overwriting, which Microsoft calls DLL stomping, was partly addressed by Windows File Protection (WFP) in Windows 2000. WFP stops unauthorized programs from replacing system DLLs unless they use the proper Windows APIs. Third-party software can only overwrite OS files if it bundles official Windows updates, disables WFP during installation, or, on Windows Vista and later, takes ownership of system files and grants itself access.
The System File Checker (SFC) tool can undo such changes at any time. A simple manual workaround is to place different versions of a problematic DLL into each application's own folder instead of a shared system folder. This works for 32-bit and 64-bit programs, as long as the DLL doesn't use shared memory.
More in Windows Administration
Spotted an error? Know more?
Reader corrections go straight into our review queue. Suggest an edit · How this site is sourced