| Revision as of 04:37, 9 December 2004 edit202.2.56.50 (talk) Update to include mention of .net assemblies to fix versioning and deployment issues← Previous edit | Revision as of 04:48, 9 December 2004 edit undo202.2.56.50 (talk) refer origins in architecture, movement of .dll's to base foundation classesNext edit → | ||
| Line 5: | Line 5: | ||
| As time goes by, the DLL-hell problem becomes worse, since software that installed the unnecessary DLLs is unlikely to remove them when uninstalled (particularly, because other applications may need them now). 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 becomes worse, since software that installed the unnecessary DLLs is unlikely to remove them when uninstalled (particularly, because other applications may need them now). 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 was a very common phenomenon on early releases of ] systems, as they had limited facilities for system file management and versioning of libraries (and existing programs often disrespected the few facilities that did exist). Other systems, while not immune to the problem, are not known for the widespread occurrence of DLL-hell seen with the pre- ] framework |
DLL-hell as described above was a very common phenomenon on early releases of ] systems, as they had limited facilities for system file management and versioning of libraries (and existing programs often disrespected the few facilities that did exist). Other systems, while not immune to the problem, are not known for the widespread occurrence of DLL-hell seen with the pre- ] framework versions of Windows. | ||
| There are several measures known to avoid DLL-hell, which have to be used simultaneously for optimal results: | There are several measures known to avoid DLL-hell, which have to be used simultaneously for optimal results: | ||
| Line 17: | Line 17: | ||
| * 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 won't be used anywhere else, they can be linked statically, with no space penalty and with a speed gain. | * 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 won't be used anywhere else, they can be linked statically, with no space penalty and with a speed gain. | ||
| Around 2001, Microsoft introduced the ] framework |
Around 2001, in response to escalating development and support costs induced by the chaos of DLL-hell, Microsoft introduced the ] framework to introduce their own version of a package deployment system, called ''assemblies'' (see external reference below). 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 ] and Windows NT, which shared a common operating system ], ]. | ||
| Pre-] ] suffered from related but technologically different problems known as ]s. | Pre-] ] suffered from related but technologically different problems known as ]s. | ||
Revision as of 04:48, 9 December 2004
DLL-hell is a colorful term given to any problem based on a difficulty in managing Dynamic Link Libraries (DLLs) installed on a particular copy of an operating system. This includes conflicts between various versions of these libraries, difficulty in obtaining a large number of such libraries, and/or having many unnecessary copies of different versions (which can cause both disk space and performance problems).
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 becomes worse, since software that installed the unnecessary DLLs is unlikely to remove them when uninstalled (particularly, because other applications may need them now). 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 was a very common phenomenon on early releases of Microsoft Windows systems, as they had limited facilities for system file management and versioning of libraries (and existing programs often disrespected the few facilities that did exist). Other systems, while not immune to the problem, are not known for the widespread occurrence of DLL-hell seen with the pre- .NET framework versions of Windows.
There are several measures known to avoid DLL-hell, which have to be used simultaneously for optimal results:
- Ship the operating system with a capable package management system that would be able to track the DLL dependencies. Declare that the use of the package manager is a good thing, and performing manual installs is a bad idea.
- Have 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 use static linking against their own version, or create a new package (with a different name) for the 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 won't be used anywhere else, they can be linked statically, with no space penalty and with a speed gain.
Around 2001, in response to escalating development and support costs induced by the chaos of DLL-hell, Microsoft introduced the .net framework to introduce their own version of a package deployment system, called assemblies (see external reference below). 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 VMS and Windows NT, which shared a common operating system architect, Dave Cutler.
Pre-Mac OS X Apple Computer suffered from related but technologically different problems known as extension conflicts.
DLL-hell is an example of an anti-pattern.