Not What You Meant? There are 75 definitions for Hell.

DLL hell

About 6 pages (1,692 words)

Questions on this topic? Just ask!

In computing, DLL hell is due to complications that arise when working with dynamic link libraries, (DLLs), in Microsoft Windows operating systems. Although the term is Windows-specific, and the more general term is dependency hell, DLL hell is often used for dependency hell on any platform. It takes a number of forms, detailed below. This problem often shows up in a Windows alert window that reports: "A Required DLL File, xxxx, was not found" or "The procedure entry point xxxx couldn't be located in xxxx.DLL" when users try to run an application, but can also manifest itself more quietly as applications not working properly.

1 Problems
2 Causes
3 Solutions
4 DLL hell as motivation for .NET
5 See also
6 External links

Problems

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

The fundamental problem is that DLLs contain code, and different versions of library can be incompatible with different versions of the programs that expect it. Windows has been particularly vulnerable to this because of its emphasis on dynamic linking of C++ libraries and 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 the earlier version. OLE has some very strict rules to prevent this -interfaces are required to be stable, memory managers are not shared- but this is not enough as the semantics of a class can change. What is a bug fix for one application may be an expected feature of an other. Windows is vulnerable to this as the COM class table was, prior to WindowsXP, 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 people's programs.

DLL stomping

The most common and troublesome problem was overwriting a working system DLL with an incompatible version. A famous example of this was the ctl3d.dll library in Windows 3.1, that was documented by Microsoft, causing numerous variations to appear in the wild. This was solved by replacing it with a new, undocumented ctl3dv2.dll library.

Shared in-memory code pages

A subtler problem occurs because once a DLL is loaded, Windows will use the running version, until no applications are using it. Thus even if the system DLL is okay, or an application has a working local copy, if a previous application has started with an incompatible version, the new application won't work. This can manifest itself either as "an application doesn't work if a different application is running", or more mysteriously as "an application doesn't work if a different application has been run (but needn't be running any longer)": if app a loads a corrupt or incompatible library, then app b is launched and uses that library, that version will stay in memory even after app a exits (so long as app b is still running), so app b might fail to work because of app a, even though app a is no longer running.

Causes

DLL incompatibility was possible because Windows lacked a number of features:

enforced standard versioning, naming, and file system location schema for DLLs;
enforced standard method for software installation and removing (package management);
centralized authoritative support for DLL Application Binary Interface management and safeguards allowed incompatible DLLs with the same file name and internal version numbers to be released;
overly simplified management tools prevented the identification of changed or problematic DLLs by users and administrators.

DLL hell was a very common phenomenon on pre-Windows 2000 versions of Microsoft operating systems, the primary cause being that the operating system did not restrict DLL installations. Application installers were expected to be good citizens and verify DLL version information before overwriting the existing system DLLs. Standard tools to simplify application deployment (which always involves shipping the dependent operating system DLLs) were provided by Microsoft and other 3rd party tools vendors. Microsoft even required application vendors to use a standard installer and have their installation program certified to work correctly, before being granted use of the Microsoft logo. 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.

Solutions

Various forms of DLL hell have been solved or mitigated over the years.

Static Linking

One of the simplest solutions to DLL hell in an application is to statically link all the libraries. This is practised in C/C++ applications, where, instead of having to worry about which version of MFC42.DLL is installed, compile the application to be statically linked against the same libraries. This eliminates the DLLs entirely, and is viable for standalone applications that are only using libraries -such as Microsoft Foundation Class Library- that offer a static option.

DLL Stomping

The DLL overwriting problem (referred to as DLL Stomping inside Microsoft) was somewhat reduced with Windows File Protection (WFP) [1] that was introduced in Windows 2000. This prevents unauthorized applications from overwriting system DLLs, unless they use the specific Windows APIs that permit this. There is still a risk that updates from Microsoft (such as Internet Explorer 7) are incompatible with existing applications, but third-party applications cannot stomp on OS files unless they bundle windows updates with their installer.

Conflicting DLLs

The solutions here consist of having different copies of the same DLLs for each application, both on-disk and in memory. An easy manual solution to conflicts was placing the different versions of the problem DLL into the applications' folders, rather than a system-wide folder. This works so long as the applications are not run simultaneously. However, [OLE] prevented this before Windows XP, because earlier versions of Windows had a single registry of COM objects for all applications. The XP solution is Side-by-Side Component Sharing (MSDN page), which loads separate copies of DLLs for each application that requires them (and thus allows applications that require conflicting DLLs to run simultaneously). This eliminates conflicts, but also eliminates one of the primary benefits of sharing DLLs between applications – reducing memory use (with modern computers which have plenty of disk space and memory, it can be a reasonable approach). Other benefits such as bug fixes and security updates may be affected, and errant and insecure DLLs may not be updated during automated processes.

Countermeasures

There are several countermeasures known to avoid DLL hell, which have to be used simultaneously for optimal results:

Registration-free COM: Windows XP introduced a new mode of COM object registration called "Registration-free COM" that was not well-publicized due to the simultaneous release of information related to .NET. This feature makes it possible for applications that need to install COM objects to store all the required COM registry information in the application's directory, instead of in the global registry, where strictly speaking if only a single application will ever use it is all that is needed. Thus, it provides a mechanism for multiple versions of the same DLL to be present at the same time as needed to cater for multiple applications (Microsoft calls this "Side-by-side Assemblies" [2]). DLL hell can be substantially avoided using Registration-free COM, the only limitation being it requires at least Windows XP or later Windows versions and that it must not be used for EXE COM servers or system-wide components such as MDAC, MSXML, DirectX or Internet Explorer.
Shipping the operating system with a capable package management system that is able to track the DLL dependencies, encouraging the use of the package manager and discouraging manual installation of DLLs.
Having a central authority for distributing the library. Changes to the library can be submitted to this authority; thus, it can make sure compatibility is preserved in the developed branches. If some older software is incompatible with the current library, the authority can provide a compatibility interface for it, or bundle the old version as a distinct package.
If software developers need to customize a library, and if the main library release is unlikely to incorporate the changes that they need, they can ship the customized DLL for the program's private use (commonly by placing it in the program's private directory) or statically link the program against the customized library.
Proper software design is paramount. DLLs are best for modularizing applications and the system's components and as third-party libraries; their usage is not imperative in all cases. For example, if an application needs a library that will not be used anywhere else, it can be linked statically, with no space penalty and with a speed gain.

DLL hell as motivation for .NET

In February of 2002, Microsoft publicly unveiled the .NET Framework which included a new version of a package deployment system, called assemblies [3]. This framework also provided support for a common language runtime (essentially moving much DLL code to a base foundation class). This concept, along with file versioning, is often seen as one of the last operating system constructs that had failed to bridge the gap between OpenVMS and Windows NT, which shared a common operating systems architecture.