DLL hell is an umbrella term for the complications that arise when one works with dynamic-link libraries (DLLs) used with older Microsoft Windows operating systems,[1] particularly legacy 16-bit editions, which all run in a single memory space.
Shared libraries allow common code to be bundled into a wrapper, the DLL, which is used by any application software on the system without loading multiple copies into memory.
DLLs have no built-in mechanism for backward compatibility, and even minor changes to the DLL can render its internal structure so different from previous versions that attempting to use them will generally cause the application to crash.
Even minor changes to the DLL code can cause this directory to be re-arranged, in which case an application that calls a particular method believing it to be the 4th item in the directory might end up calling an entirely different and incompatible routine, which would normally cause the application to crash.
There are several problems commonly encountered with DLLs, especially after numerous applications have been installed and uninstalled on a system.
Object Linking and Embedding has very strict rules to prevent this: interfaces are required to be stable, and memory managers are not shared.
A common and troublesome problem occurs when a newly installed program overwrites a working system DLL with an earlier, incompatible version.
DLL incompatibility has been caused by: DLL hell was a very common phenomenon on pre-Windows NT versions of Microsoft operating systems, the primary cause being that the 16-bit operating systems did not restrict processes to their own memory space, thereby not allowing them to load their own version of a shared module that they were compatible with.
Application installers were expected to be good citizens and verify DLL version information before overwriting the existing system DLLs.
The good-citizen installer approach did not mitigate the problem, as the rise in popularity of the Internet provided more opportunities to obtain non-conforming applications.
Malwares can exploit this behavior in several ways collectively known as DLL search order hijacking.
However, the main purpose of DLLs – runtime library sharing between programs to reduce memory overhead – is sacrificed; duplicating library code in several programs creates software bloat and complicates the deployment of security fixes or newer versions of dependent software.
[11] This prevents unauthorized applications from overwriting system DLLs, unless they use the specific Windows APIs that permit this.
This approach eliminates conflicts by allowing applications to load unique versions of a module into their address space, while preserving the primary benefit of sharing DLLs between applications (i.e. reducing memory use) by using memory mapping techniques to share common code between different processes that do still use the same module.
[13] One negative side effect is that orphaned instances of DLLs may not be updated during automated processes.
[11] The mechanism relies on applications not fully qualifying the paths to dependent DLLs when loading them, and the operating system searching the executable directory before any shared location.