DLL hell

As originally conceived, DLLs must be version-to-version compatible and interchangeable in both directions.

The implementation of the DLL mechanism is such that incompatibility and non-interchangeability become the rule rather than the exception, which leads to a lot of problems.

• The lack of standards for the names, versions, and location of DLLs in the file structure makes incompatible DLLs easily replace or disconnect each other.
• The lack of a standard for the installation procedure leads to the fact that the installation of new programs leads to the replacement of working DLLs with incompatible versions.
• The lack of support for DLLs on the part of linkers and security mechanisms means that incompatible DLLs may have the same name and version.
• There are no standard tools for identifying and managing the DLL system by users and administrators.
• Using separate DLLs to provide communication between tasks leads to instability of complex applications.

To avoid conflicts, they usually use a lot of redundant copies of DLLs for each application, which negates the original idea of ​​taking advantage of DLLs as standard modules stored once in memory and shared by many tasks. In addition, with this experience, after fixing errors in the DLL or restoring the system from the archive, the number of different DLLs that have the same name and perform the same functions increases, and automatic updating of the version or correction of errors becomes impossible.

This issue arose in earlier versions of Microsoft Windows .

Earlier versions of Mac OS X faced similar problems, but using other technologies.

The problem is constantly repeated when they try to run the program with the wrong DLL from which it was tested, which shows the initial viciousness of the general concept, which allows arbitrary replacement of module versions.

These measures are recommended to be taken simultaneously to obtain the best result:

• calculate the checksum of the code of the function called from the DLL - compare with the checksum of the function used when writing the program.
• The operating system should be delivered together with the package manager in order to be able to trace all the interdependencies of the DLL, while the use of the package manager should be encouraged, and individual installation of the DLL should be discarded whenever possible.
• Centralized distribution of libraries.
• To allow the possibility of parallel use of several versions of the same DLL [1] .
• When modifying software for private use, also supply modified versions of the DLL.
• During the design of a DLL, the concept of functions and versions must be carefully considered.
• DLLs should not be used unnecessarily, and libraries associated with only one application should be connected statically (in an EXE file).

In 2001, Microsoft defined the .NET Framework for package development ( assemblies : see here ). This subsystem began to support a common runtime library by attaching a DLL to the main executable class.

• DLL Hell, the Inside Story
• How to avoid the nightmare of DLLs
• Simplifying Deployment and Solving DLL Hell with the .NET Framework
• .NET and DLL Hell

• Side-by-side assembly
• Windows file protection
• Windows Resource Protection
• Linker
• Dynamic link library
• Global assembly cache