|WikiProject Computing||(Rated Start-class, Low-importance)|
|Sources for development of this article may be located at|
- 1 Deleted paragraphs
- 2 Hyphen
- 3 Category:Windows
- 4 Windows as the origin of the term
- 5 DLL Hell and Unix
- 6 Mac OS X comment
- 7 The article starts off wrong
- 8 Lack info
- 9 Dangling Modifier
- 10 Mac Extensions
- 11 DLL hell today
- 12 Not a Windows-specific term
- 13 "In Computing"?
- 14 Cleanup required
- 15 Windows-specific
- 16 Underlying problem
- 17 Item 2. Causes - may need clarification?
- 18 Causes
- 19 Causes
- 20 Manifest hell
- 21 Before when exactly?
- 22 Article name
- 23 Solutions
There isn't all that much information in the deleted paragraphs.
The first deleted paragraph boils down to:
- GNOME installs a lot of stuff
- Linux suffers from "header-hell"
Neither one of these statements says very much.
The second deleted paragraph actually does have a little bit of information.
- Should be called so-hell on Linux (conversational fluff)
- Using a package manager helps (redundant with the avoidance methods list)
- libc version incompatibilities (could serve as an example, if rewritten)
- Open source lets you recompile (not really relevant)
The initial reason for evaluating the value of those paragraphs was a complaint on Wikipedia:Pages_needing_attention about the page going off on tangents.
--Cyrius 00:16, 28 Dec 2003 (UTC)
Feels kind of wasteful to get rid of all that information on Linux libraries. Why not put it in a new article with mutual links? --cprompt 08:41, 25 Dec 2003 (UTC)
I'm missing the reasoning for the hyphen in "DLL-hell" as opposed to "DLL Hell" or "DLL hell", and would appreciate others' input. Since, to my knowledge, the hyphen's most common use is to combine multiple words into a single adjective, I find it very jarring to read text which uses the hyphenated form to describe a place. Ventura 19:03, 2004 Jul 29 (UTC)
- I think I'd agree. In fact, I'm going to move the page right now, and see if anyone can give me a good reason to move it back. - IMSoP 14:17, 16 Jan 2005 (UTC)
Why is this in Category:Windows? It implies that this phenomenon is Windows-specific, but any operating system that supports dynamically loaded libraries can suffer "DLL hell," including Linux. I'm removing the category. --Ardonik 03:44, 2004 Aug 6 (UTC)
Windows as the origin of the term
I'm hesitant to just add this straight in, since there has already been discussion about the fact that DLL hell itself isn't Windows specific, but I'm thinking that the name probably is. As in, although DLL is just an acronym for "Dynamincally Linked Library", it is only commonly used because this is how MS Windows refers to files of this type - their file extension is ".dll", and they are commonly known by that term. And, as the article does mention, Windows is particularly infamous for this problem. So would it be worth making clear in the article that while the phenomenon can occur on any OS, with whatever kinds of libraries are around, the term comes from its occurrence on Windows, with "DLL files"? - IMSoP 14:49, 16 Jan 2005 (UTC)
- The title probably should be Dynamic Link Library Hell. Sam Tomato (talk) 18:19, 6 November 2014 (UTC)
DLL Hell and Unix
To what extent do popular unix variants (e.g. Solaris and Linux) suffer from DLL Hell? Funkyj 19:15, 2005 May 27 (UTC)
Mac OS X comment
Under avoidance measures; "Use an alternate operating system which does not have dependance on DLLs such as Mac OS X"
Is this necessary? The avoidance measures section seems aimed more toward developing a DLL-based system that avoids the problems of DLL Hell. The OS X comment, to me, seems more like a snide bit of OS preaching than anything else. Should it be removed? --Ajudd 09:39, 5 Jun 2005 (PDT)
I think so. I love Mac OS X, but the comment is really off-topic. I'm going to remove it. --Chuck 09:59, 5 Jun 2005 (PDT)
The article starts off wrong
And things go downhill. I publicly coined the term "DLL Hell", altho it was used internally at MS for some time.
>>DLL hell is an example of an anti-pattern — that is, a bad programming practice, which should be avoided in well-written software.
>>>>the term was in common usage outside of microsoft since at least the early 90s.
It's definitely not an anti-pattern, unless you're talking about the OS. The most common DLL problems afflicted well-written software (including well written installers) when poorly written installers stomped on system DLLs.
DLL was first addressed (and still is primarily to this day) via WFP, not even mentioned in the article.
I can do some work on this, but not now (I'm too swamped with LHS). I can get some unix references on DLL Hell.
- Rick Anderson (still at MS) Ricka0 21:41, 6 March 2006 (UTC)
See dependency hell, which I put in the category anti-patterns by analogy with this, with a remark that the problem is in the framework rather than the products. I feel that the occurence on both platforms suggests there is an anti-pattern (which I reckon should be seen as a recognisable type of wrong approach to a recognisable problem) in there.
- PJTraill 18:00, 12 March 2006 (UTC)
Please review my changes - it should make it obvious why DLL Hell is the nothing close to an anti-pattern. There are still many flaws in the article, but I have a good start. I'm sure my formatting needs some work, this is the first major wikiPedia change I've made (altho I made some corrections in Win03 that were accepted).
- Rick Anderson (still at MS)Ricka0 04:14, 23 March 2006 (UTC)
One more section completed. The Countermeasures section is mostly incorrect. I question if the authors have ever delivered an application for Windows. The article desperately needs a definition section (Type I, II, etc)
- Rick Anderson (still at MS)Ricka0 08:25, 25 March 2006 (UTC)
I often see it said that Microsoft itself introduced the phrase “DLL Hell”. Is that correct? In my opinion it would help to provide a clear answer to that question in the article.
INsufficient info about DLl hooks/Injections and things windows loads at bootup. Please expand.Linux Librarys should be included too.
ricka writes --
Win boot up is an interesing topic but not directly related to DLL Hell, ditto for DLL hooks, injections. DLL Hell hasn't yet been properly defined (my next step)
Who keeps adding bogus external links (and does so anonymously?) still at MS Ricka0 23:35, 1 April 2006 (UTC)
"The canonical example ... is time slice multiplexing in Microsoft operating systems before OS2 and Windows NT (which includes Windows NT 3.51, Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003)."
What does "which" refer to? I suspect that it's supposed to refer to "Windows NT," but is it strictly true that Windows XP, for example, is actually included within Windows NT?
On the other hand, if "which" refers to operating systems like Windows NT, including those mentioned, it needs a precedent. I don't think it should refer to something unmentioned, whether implied or not.
I recommend deleting the entire parenthesis. D021317c 19:16, 5 May 2006 (EDT)
nuked which (Ricka0 01:09, 14 May 2006 (UTC)).
I removed a line likening DLL Hell to the extension conflict situation on Mac OS (pre X). Perhaps I ought to explain myself. The line claimed that the situation was analogous. It isn't. Extensions are not routinely installed by applications, nor are applications ever (in normal circumstances) dependent on them as they would be a DLL. Extension conflicts are caused by multiple extensions patching the same OS routines without considering that they may already be patched. Overwriting an extension with a more up to date one rarely contributed to the problem. Since Mac OS also has the equivalent of DLLs (shared libraries), there is a far more apposite component of the OS to compare with. However, Mac OS doesn't suffer from anything like the same degree of pain that Windows does in this respect. Part of this has to do with the design of the shared library - there is strong versioning in place and the shared library manager will manage this effectively. Secondly, most shared libraries are delivered as part of the OS, and so tend to be consistent with older versions. The situation where third parties add lots of shared libraries on Mac OS is rare. Finally, it's also in part down to the culture of Mac programmers. For various reasons we tend to be very defensive when coding Mac apps, so recklessly making assumptions about shared lib versions, etc is rare too. While I have come across something like shared library conflicts on Mac OS, it's just not a major problem in practice. If somebody wants to mention Mac at all in the article (I don't see why really except for advocacy which doesn't belong here), then the comments should be relevant. Graham 08:55, 15 May 2006 (UTC)
DLL hell today
Not a Windows-specific term
Contrary to what someone has written several times on this talk page, this term is commonly used in Unix-like environments. It is a false analogy to point to Dependency hell as the Unix analog considering that that article only deals with package managers on Linux, and not, say, shared libraries. While shared library is the prefered term for DLLs on Unix, the term DLL is also sometimes used. The article makes the false conclusion that this term is specific to Windows. Windows is not actually the only OS to call its shared libraries DLLs (OS/2 for example). –Andyluciano 17:35, 6 December 2006 (UTC)
- I have never heard of DLL Hell used to refer to dependency hell in UNIX.--188.8.131.52 01:19, 21 March 2007 (UTC)
- I have used UNIX since 1978 and have been system admin and system programmer and never heard the term used except under Windows. Perhaps it is sometimes but I doubt it is used commonly under UNIX, esp. as it is much less of a problem there. The term certainly originated under Windows. Also OS/2 is not a good example as an alternative OS as it is an antecedent of Windows 32. —Preceding unsigned comment added by 184.108.40.206 (talk) 09:00, 9 October 2007 (UTC)
I've seen quite a few implementation-specific articles start with "in computing." "DLL Hell" is not something found "in computing," it is something found in Windows (just as "RPM Hell" is not a general computing term, but something that applies specifically to RPM based Linux distributions). It seems that "In computing" would be a more suitable in articles about linked lists, hashes, processor registers, page files, exceptions, etc, etc. If "DLL hell" is something that occurs "in computing" then it must take place (or have the potential to take place) under Mac OSX, Linux, on my calculator and so on.
I was wondering if anyone could shed some light on why these articles have this phrase at the start of them. —The preceding unsigned comment was added by 220.127.116.11 (talk) 01:08, 21 March 2007 (UTC).
This article doesn't read smoothly at all. A lot of cleanup is required. Pramod 13:30, 24 March 2007 (UTC)
I've added a note at the start saying that the term is properly Windows-specific, but catchy and used (loosely) more widely. Hopefully this addresses the discussion above. Nbarth 19:36, 28 May 2007 (UTC)
The text doesn't explain the underlying problem of incompatibility well at all. The so called "DLL stomping" is a secondary problem. I recommend adding the following problems before the DLL Stomping one:
* Backward compatibility
Implicit in the idea of DLLs is that when a new version of a DLL is produced it should be completely backward compatible with all previous versions. In an imperfect world this fails for several reasons:
- A program that uses a DLL can have subtle dependencies on its behavior, which changes in a later version. This is usually blamed on the program for taking advantage of undocumented behavior but is often better ascribed to the fact that the external interface to the DLL is poorly documented.
- It is unclear who has authority to update a particular DLL which can result in diverging variations.
- The DLL implementor may be oblivious to any requirement for backward compatibility.
- A newer version may simply be released with new bugs.
- Two DLLs may be independently produced that have the same name and can be accidentally use in place of each other.
* Forward compatibility
A program may make use of features of a particular version of a DLL but fail if it inadvertently ends up using an earlier version. This is generally prevented by installation software that only overwrites an existing DLL with a later version, but often occurred in the past when badly-made or home-spun installation software was used.
This is exacerbated by the fact that some DLLs do not provide any means to check their version. Also the implementor of the program calling the DLL may be unaware that there are earlier versions and not allow for the possibility.
- added some of this content, though more details are welcomed. Is there some offical sofware engineering page of 'versioned interfaces/implementations' that I could link to cover the fundamental problem, of which DLL-hell in windiws is merely a worst-case example. —Preceding unsigned comment added by SteveLoughran (talk • contribs) 23:04, 5 December 2007 (UTC)
Item 2. Causes - may need clarification?
Under the Causes heading is the following:
DLL incompatibility was possible because Windows lacked a number of features:
- 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;
I am finding this article fascinating, and seems to explain some of the grief that one encounters, particularly with the older versions of Windows OS.
However, in my reading, I came across the text above, and ask for a more experienced person than I, who understands the subject matter, to clarify this point?
It tells me that Windows lacked certain features. One such feature is "centralized authoritative support for DLL Application Binary Interface management and safeguards." If this safeguard were in place, it would have "allowed incompatible DLLs with the same file name and internal version numbers to be released?"
I don't think that is what the author intended, because I am thinking the stuff after "allowed" is the problem suffered by Windows because Windows lacked the features listed.
Would this be a better presentation:
DLL incompatibility was possible because Windows lacked a number of features:
- centralized authoritative support for DLL Application Binary Interface management and safeguards, WHICH WOULD HAVE PREVENTED
allowedincompatible DLLs with the same file name and internal version numbers FROM to beBEING released;
- What section are you referring to specifically? I can't seem to find mention of manifests anywhere, other than the link that I added to Side-by-Side Assembly. - Reinderientalk/contribs 01:13, 27 February 2009 (UTC)
Before when exactly?
In the section Incompatible versions it states "Before Windows 2000, Windows was vulnerable to this because the COM class table was shared across all users and processes."
One of the solutions I used (at one of the software shops I used to work at) was DLL file version naming. Specifically, we would name our DLL filenames to include the version number of a particular release. So rather than distributing the file
, we would distribute
, which specifically indicated version 1.2 of our code. This scheme prevented overwriting of previously existing (working) library versions during customer installs, and also allowed customers to run multiple version of our software simultaneously. This approach could also be applied to the MS redistributable system libraries. This works because executables linked to DLLs refer to those DLLs specifically by their filename, so adding extra characters to the DLL filenames allows for differentiating between different versions of those DLLs. I do not see anything like this simple solution listed in the article. — Loadmaster (talk) 17:19, 4 June 2014 (UTC)