DLL hell

related topics
{system, computer, user}
{math, number, function}
{work, book, publish}
{god, call, give}
{law, state, case}
{company, market, business}

In computing, DLL hell is a colloquial term for the complications that arise when working with dynamic link libraries (DLLs) used with Microsoft Windows operating systems, particularly legacy 16-bit editions which all run in a single memory space. Although the term is Windows-specific (the more general term is dependency hell) the rhyme is often used to depict a dependency hell case.

DLL hell often shows up in a Windows alert pop-up that reports something similar to "A Required DLL File, Z.DLL, was not found" or "The procedure entry point Y couldn't be located in X.DLL" when users try to run an application, or during startup. This can also manifest itself more quietly as applications not working properly. It takes a number of forms, as detailed below.



There are a number of problems commonly encountered with DLLs – especially after numerous applications have been installed and uninstalled on a system. The difficulties include conflicts between DLL versions, difficulty in obtaining required DLLs, and having many unnecessary DLL copies.

Incompatible versions

A particular version of a library can be compatible with some (and incompatible with other) programs that use it. Windows has been particularly vulnerable to this because of its emphasis on dynamic linking of C++ libraries and Object Linking and Embedding (OLE) objects. C++ classes export many methods, and a single change to the class (such as a new virtual method) can make it incompatible with programs that were built against an earlier version. Object Linking and Embedding has some very strict rules to prevent this—interfaces are required to be stable and memory managers are not shared. But this is not enough, for the semantics of a class can change. A "bug fix" for one application may be the removal of a "feature" from another. Before Windows 2000, Windows was vulnerable to this because the COM class table was shared across all users and processes. Only one COM object, in one DLL/EXE could be declared as having a specific COM ClassID. If any program needed to create an instance of that class, it got whatever was the current centrally registered implementation. As a result, an installation of a program that installs a new version of a common object may inadvertently break other programs that were previously installed.

Full article ▸

related documents
Software testing
TI-89 series
Colossus computer
Linux distribution
Digital signal processing
Windows 1.0
Java Message Service
Video codec
Wikipedia:Federal Standard 1037C terms/telecommunication network terms
Internet Protocol Suite
AOL Instant Messenger
Tape drive
Distributed computing
Intel 8085
Packet switching
Intel 80386
Digital audio
Extended Industry Standard Architecture
Amiga 500
Whirlwind (computer)
Game Boy line
Address Resolution Protocol