DLL hell

Encyclopedia : D : DL : DLL : DLL hell

In computing, DLL hell is a colourful phrase for complications which arise when working with dynamic link libraries, or DLLs. The term was introduced to the general public by Rick Anderson in his January 2000 paper, The End of DLL Hell, after having been in use within Microsoft for some time.

DLL Hell encompasses the difficulties of managing dynamic-link libraries (DLLs) in Microsoft Windows operating systems. These difficulties include conflicts between DLL versions, difficulty in obtaining required DLLs, and having many unnecessary DLL copies. DLL Hell is an example of a latent operating system design flaw — that is, problems occur in well-written programs because of bad programming practice or a bug in poorly-written software that is tolerated by the operating system. The canonical example of a latent operating system flaw is time slice multiplexing in Microsoft operating systems pre-dating OS2 and Windows NT. With time slicing, a rogue or buggy program can effectively disable the entire computer, forcing the user to hard boot the machine.

Contents

1 Problems
2 Instances
3 Countermeasures
4 DLL hell as motivation for .NET
5 References
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 most common and troublesome problem was overwriting a working system DLL with a version causing some applications to fail. The DLL overwriting problem (referred to as DLL Stomping inside Microsoft) was largely solved with Windows File Protection (WFP) [link] that was introduced in Windows 2000. Before WFP, DLL incompatibility was possible for the following reasons:

The lack of enforced standard versioning, naming, and file system location schema for DLLs.
The lack of an enforced standard method for software installation.
The lack of a 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; and
The lack of simple management tools prevents the identification of changed or problematic DLLs by users and administrators.

Some preventive measures such as Side-by-Side Component Sharing[link] create redundant copies of DLLs, each to be loaded separately for each application that requires them – effectively eliminating one of the primary benefits of sharing DLLs between applications – reducing memory use. Other benefits such as bug fixes and security updates may be affected, and errant and insecure DLLs may not be updated during automated processes.

Instances

DLL hell as described above was a very common phenomenon on pre-Windows 2000 versions of Microsoft operating systems, the primary cause being 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.

James Donald, in his 2003 paper titled Improved Portability of Shared Libraries[link] argued that DLL Hell is worse under Linux than Microsoft Windows. Several Linux distributions have had problems with software not packaged for the distribution when updating libraries, since the application programming interfaces of some Open Source libraries are prone to change between releases. When occurring in non-Windows environments, these problems are often referred to as dependency hell. However, it should not be confused with DLL hell, as DLL hell is a specific type of dependency hell.

A modern example of dependency hell on Microsoft Windows, Linux, and Mac OS X is the Gecko Runtime Engine or GRE used by Mozilla projects. Each product released from the Mozilla foundation includes its own version of the complete Gecko Runtime Engine, due to the volatile nature of the programming interfaces used. Thus, if a user installs Thunderbird, Firefox, and Sunbird, there will be three copies of GRE on the machine. These may or may not be compatible, depending on when the GRE source tree was forked. Some external projects like Epiphany depend on specific versions of the Mozilla Suite to use GRE, and break if a different version is installed; while others such as Nvu bring their own copy of GRE.

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 lost in the .NET hype. 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" [link]). 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 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

Around 2001, Microsoft introduced the .NET Framework to introduce their own version of a package deployment system, called assemblies [link]. This framework also provided support for a common library 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 architect.

References

External links

[The End of DLL Hell] on MSDN
[Simplifying Deployment and Solving DLL Hell with the .NET Framework] on MSDN
[Avoiding DLL Hell: Introducing Application Metadata in the Microsoft .NET Framework] by Matt Pietrek

From Wikipedia, the Free Encyclopedia. Original article here. Support Wikipedia by contributing or donating.
All text is available under the terms of the GNU Free Documentation License See Wikipedia Copyrights for details.