Dll conflict
The expression DLL conflict (also known as DLL Hell , German: "DLL Hell") describes a problem that can arise from the installation of dynamic link libraries (DLLs) on the operating systems of the Windows series. Older Windows versions are mainly affected, as these only have limited options for managing system files and DLL libraries. Older versions of Mac OS also have similar problems known as Extension Conflicts . In the various Linux distributions , library conflicts are usually prevented by the distribution's own package manager, but not always.
The problem
In principle, DLLs allow computer programs to access their program code and their resources in order to summarize identical code that every program would otherwise have to bring along. However, new programs often bring new versions of an existing DLL (shared library) with them. The program now has the choice of overwriting the old DLL during installation (which can lead to compatibility problems with other programs) or installing another copy on the system.
Virtual memory enables the process management of an operating system to store large parts of shared libraries in shared pages of physical memory. If many programs use the same library, the total memory requirement is significantly smaller than the sum of all processes. This procedure assumes that the file is the same, not just identical content. Multiple copies of the same library that are used therefore not only require additional hard disk space, but also more memory .
The more old and new programs are used together, the greater the risk of DLL conflicts. This can lead to an unmanageable number of different DLL files, some of which are required by the operating system itself (and therefore must not be removed under any circumstances), but some also represent unneeded remnants of deleted installations.
On modern systems it can be assumed that the available hard disk capacity will hardly be affected by redundant DLL versions. However, similar to orphaned entries in the system registry, the mere fact that the system is becoming more and more chaotic and therefore uses up computing power for no good reason and creates potential instabilities is a fundamental problem.
causes
DLLs are required by different programs in different versions, but are usually stored in a central location (in the Windows or system directory) and entered in the Windows registry . This saves memory space and can significantly accelerate program execution, since the system needs less time to find the right DLL version for the program. On the other hand, installing a new program can result in a new DLL overwriting the old version. The new version may cause compatibility problems with the older software due to poor or imprecise specification of the interface or incorrect use of the programming interface . This is a sign of poor software design . Such problems are often triggered by the use of undocumented function calls by the application developer or by unspecified changes in the behavior of a DLL by the library developer.
With Macintosh operating systems, this disadvantage is avoided in that such system files are not stored in a central location, but in the respective program directory. This redundancy not only leads to the use of additional hard disk space, but can also lead to a loss in the computing power of a system. However, due to the enormous increase in hard disk capacities and the high computing power of modern processors, these disadvantages have faded into the background.
Methods of avoidance
There are tried and tested methods that can be used to avoid these DLL conflicts. However, these recommendations can only be effective if implemented in their entirety.
- In principle, it has to be considered whether the potential disadvantages of a DLL are outweighed by the advantages in a specific application. If a DLL does not achieve the goal of being able to be used modularly by many programs at the same time, it is better if its function is taken over directly by the program.
- If software developers need to make changes to a DLL and the original library cannot be integrated into the new one, they can incorporate the program code directly into their program (the library is statically linked).
- Locally stored DLL versions for a specific program called private DLLs . Under Windows, these DLL versions, which are stored in the application's program folder, have a higher priority than the DLLs available throughout the system.
- Microsoft .NET allows programs to either store their own DLLs in the program directory or to store them centrally in the Global Assembly Cache (GAC), whereby the GAC can provide each installed program with the version of the DLL it requires.
- Specification of a version designation in the DLL file name (e.g. atl80.dll, atl90.dll) so that different versions can be installed together.
- Installation programs or package managers can track DLL dependencies of programs.
- Have libraries managed centrally by the operating system. Such a central administration can, for example, check the compatibility of old library versions with new ones and, should such a version compatibility not exist, guarantee this again by installing an interface in the library.
DLL conflicts as a challenge for .NET
In 2001 Microsoft published the .NET programming environment, which contains its own package management system, the so-called assemblies . This environment provides much-used functions in a library. In particular, program code from several DLLs is combined in one class.
In .NET each program can use its own libraries and store them in the root directory of the program. Alternatively, assemblies can also be stored centrally in the Global Assembly Cache (GAC) . In contrast to earlier Windows systems, however, this is able to manage several versions of an assembly ( side-by-side assembly, WinSxS ), so that each running program is assigned the version of the DLL with which it is linked.
The idea of managing different versions of a file is sometimes seen as a remnant of outdated programming techniques. For example, it cannot be ruled out that outdated program versions with publicly known security holes will continue to run, even if a newer, more secure version is installed.
swell
- ↑ a b Rick Anderson: The End of DLL Hell ( English ) microsoft.com. January 11, 2000. Archived from the original on June 5, 2001. Retrieved July 7, 2010: “ Private DLLs are DLLs that are installed with a specific application and used only by that application. "
- ↑ Tim Pfeiffer: Windows DLLs: Threat or Menace? . Dr. Dobb's Journal . June 1, 1998. Archived from the original on August 7, 2010. Retrieved July 7, 2010.