Talk:DLL Hell

Computing Start‑class Low‑importance

	This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing articles
Start	This article has been rated as Start-class on Wikipedia's content assessment scale.
Low	This article has been rated as Low-importance on the project's importance scale.

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)

Since 2004-07-26 18:45:50 Jal in dependency hell. -- PJTraill 18:49, 12 March 2006 (UTC)[reply]

Hyphen

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)

Category:Windows

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)

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)

See link to dependency hell PJTraill 17:44, 12 March 2006 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Lack info

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)[reply]

Dangling Modifier

"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)).[reply]

Mac Extensions

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)[reply]

DLL hell today

Is this much of an issue on Windows today? It'd be nice to get some hard info. Twinxor t 04:04, 9 August 2006 (UTC)[reply]

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)[reply]

I have never heard of DLL Hell used to refer to dependency hell in UNIX.--24.67.212.211 01:19, 21 March 2007 (UTC)[reply]

"In Computing"?

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 24.67.212.211 (talk) 01:08, 21 March 2007 (UTC).[reply]

Cleanup required

This article doesn't read smoothly at all. A lot of cleanup is required. Pramod 13:30, 24 March 2007 (UTC)

Windows-specific

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)[reply]

Underlying problem

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.