| Revision as of 11:26, 26 June 2002 edit195.149.37.199 (talk) *dll-hell on linux is a different phenomenon← Previous edit | Revision as of 21:35, 26 June 2002 edit undoUriyan (talk | contribs)1,634 editsNo edit summaryNext edit → | ||
| Line 5: | Line 5: | ||
| As time goes by, the DLL-hell problem can become only worse, since software that installed the unnecessary DLLs is unlikely to remove them when uninstalled. This could eventually cause a chaos of thousands of mysterious DLL-files, some of which are necessary for the system to function normally, while others are just wasting space, and with no way to distinguish between them. | As time goes by, the DLL-hell problem can become only worse, since software that installed the unnecessary DLLs is unlikely to remove them when uninstalled. This could eventually cause a chaos of thousands of mysterious DLL-files, some of which are necessary for the system to function normally, while others are just wasting space, and with no way to distinguish between them. | ||
| DLL-hell as described above is a very common phenomenon on ] systems, as they have limited facilities for system file management and versioning of libraries (and existing programs often disrespect the few facilities that do exist). However, even with systems with standard locations for dynamic libraries and careful versioning schemes, problems may be encountered with the use of such libraries. For example, |
DLL-hell as described above is a very common phenomenon on ] systems, as they have limited facilities for system file management and versioning of libraries (and existing programs often disrespect the few facilities that do exist). However, even with systems with standard locations for dynamic libraries and careful versioning schemes, problems may be encountered with the use of such libraries. For example, the ] desktop environment running under ] is notorious for bundling an enormous number of libraries. It leads to an immediate performance loss, as well as eventual problems with programs that weren't distributed with the libraries or built from ]. It may turn out that several libraries that the programs depends on will be missing and need to be installed first. When compiling older software, problems may sometimes arise when it tries to link with a library for which a newer and incompatible version is installed. | ||
| There are several measures known to avoid DLL-hell, which have to be used together: | There are several measures known to avoid DLL-hell, which have to be used together: | ||
| * Ship the operating system with a capable package manager (such as ] for ] systems), that would be able to track the DLL dependencies. Declare using the package manager good style and using manual installs bad style. | * Ship the operating system with a capable package manager (such as ] for ] systems), that would be able to track the DLL dependencies. Declare using the package manager good style and using manual installs bad style. | ||
| * Have a central authority for distributing the library. Changes to the library can be proposed to this authority; it can also make sure compatibility is preserved in the developed branches. If older software is incompatible with the current library, the authority can provide a compatibility interface for it, or bundle the old version |
* Have a central authority for distributing the library. Changes to the library can be proposed to this authority; it can also make sure compatibility is preserved in the developed branches. If 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 are in need of customizing a library, if the main library release is unlikely to incorporate the things that they need, they can use static linking against their own version, or create a new package (with a different name) for it. | * If software developers are in need of customizing a library, if the main library release is unlikely to incorporate the things that they need, they can use static linking against their own version, or create a new package (with a different name) for it. | ||
| * 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 there's an application that needs a library that won't be used anywhere else, they can be linked statically, with no space penalty and with a speed gain. Also, some platforms support ]s between programs, a less sophisticated but more efficient interface than DLL calls. | * 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 there's an application that needs a library that won't be used anywhere else, they can be linked statically, with no space penalty and with a speed gain. Also, some platforms support ]s between programs, a less sophisticated but more efficient interface than DLL calls. | ||
Revision as of 21:35, 26 June 2002
DLL-hell is a describing term for troublesome situations caused by unnecessary copies of Dynamic Link Libraries (DLLs) installed on a particular copy of an operating system, and conflicts between various versions of these libraries.
Generally, the concept of DLLs means that many applications can share the same DLL file; however, in many cases, applications may introduce a changed version of a particular DLL which is already present on a system, either overwriting the old copy (which can, in turn, break compatibility with other applications), or install another copy, wasting disk space, memory space and slowing program load times because it takes more time to locate the right DLL among many.
As time goes by, the DLL-hell problem can become only worse, since software that installed the unnecessary DLLs is unlikely to remove them when uninstalled. This could eventually cause a chaos of thousands of mysterious DLL-files, some of which are necessary for the system to function normally, while others are just wasting space, and with no way to distinguish between them.
DLL-hell as described above is a very common phenomenon on Microsoft Windows systems, as they have limited facilities for system file management and versioning of libraries (and existing programs often disrespect the few facilities that do exist). However, even with systems with standard locations for dynamic libraries and careful versioning schemes, problems may be encountered with the use of such libraries. For example, the GNOME desktop environment running under Linux is notorious for bundling an enormous number of libraries. It leads to an immediate performance loss, as well as eventual problems with programs that weren't distributed with the libraries or built from source code. It may turn out that several libraries that the programs depends on will be missing and need to be installed first. When compiling older software, problems may sometimes arise when it tries to link with a library for which a newer and incompatible version is installed.
There are several measures known to avoid DLL-hell, which have to be used together:
- Ship the operating system with a capable package manager (such as RPM for RedHat systems), that would be able to track the DLL dependencies. Declare using the package manager good style and using manual installs bad style.
- Have a central authority for distributing the library. Changes to the library can be proposed to this authority; it can also make sure compatibility is preserved in the developed branches. If 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 are in need of customizing a library, if the main library release is unlikely to incorporate the things that they need, they can use static linking against their own version, or create a new package (with a different name) for it.
- 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 there's an application that needs a library that won't be used anywhere else, they can be linked statically, with no space penalty and with a speed gain. Also, some platforms support pipes between programs, a less sophisticated but more efficient interface than DLL calls.