Talk:DLL Hell

Deleted paragraphs

There isn't all that much information in the deleted paragraphs.

The first deleted paragraph boils down to:

1. GNOME installs a lot of stuff
2. 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.

1. Should be called so-hell on Linux (conversational fluff)
2. Using a package manager helps (redundant with the avoidance methods list)
3. libc version incompatibilities (could serve as an example, if rewritten)
4. 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)

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)

Is "DLL" not Windows-specific? Sam Tomato (talk) 18:17, 6 November 2014 (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)

See link to dependency hell PJTraill 17:44, 12 March 2006 (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.

Sam Tomato (talk) 18:24, 6 November 2014 (UTC)

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)

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)).

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)

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)

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.--24.67.212.211 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 203.110.131.5 (talk) 09:00, 9 October 2007 (UTC)

Linux suffers DLL Hell problems. And I'm pretty sure some of the Unix'es suffer the problem, like AIX. The best way to avoid DLL Hell on Linux is not build and install a package yourself. Always use the distro's version of a package.

I'm not sure what is called when Linux suffers the problems. I've always called it DLL Hell because no one has really coined a term for it on Linux.

Also see Tim Brown's Breaking the links: Exploiting the linker. He shows Linux suffers the same problems as Windows.

Jeffrey Walton (talk) 12:32, 28 November 2020 (UTC)

"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).

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)

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.

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)

---

—Preceding unsigned comment added by 203.110.131.5 (talk) 07:05, 3 October 2007 (UTC)

Item 2. Causes - may need clarification?

Under the Causes heading is the following:

Causes

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:

Causes

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 allowed incompatible DLLs with the same file name and internal version numbers FROM to be BEING released;
• ....

--Larry (talk) 18:14, 4 March 2008 (UTC)

Manifest hell

Is anyone familiar with this term and would like to expand more on this in the article? - xpclient ^Talk 12:53, 23 February 2009 (UTC)

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. - Reinderien^{talk/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."

I don't remember using COM well enough that far back - but were NT4 / NT3.x vulnerable to that problem, or was it just a 9x fault? Number774 (talk) 11:11, 10 July 2009 (UTC)

Article name

The following discussion is an archived discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the move request was: page moved per discussion. This was a hard call, but the sources use it as a proper noun, and the grammatical argument leaves room for doubt. - GTBacchus^(talk) 01:52, 19 July 2011 (UTC)

---

DLL hell → DLL Hell – It's a proper name, and all the refs use it as such.Socrates2008 (Talk) 11:51, 27 June 2011 (UTC)

• Support: Proper noun. –CWenger (^ • @) 00:03, 28 June 2011 (UTC)
• Support Yeah, all RS use capital H, or use it most of the time. --Enric Naval (talk) 20:40, 29 June 2011 (UTC)
• Support. Per the refs. - Yk³ talk ~ contrib 00:12, 30 June 2011 (UTC)
• Support. Following the sources. Quigley (talk) 08:23, 30 June 2011 (UTC)
• Oppose hate to say this, but this is not a proper noun, as it is a concept or state of being which can incur for multiple people or instances, not a physical place. Even if sources use a capital, we do not follow suit even though other people make grammatical mistakes. Arsenikk ^(talk) 23:24, 2 July 2011 (UTC)
• Strongly oppose as per Arsenikk. Definitely not a proper noun. 1exec1 (talk) 13:47, 3 July 2011 (UTC)

On what grounds? Rick Anderson, who wrote the seminal article on the subject, used it as a proper noun; so does every other article from the vendor, Microsoft.1, 2, 3, 4. Socrates2008 (Talk) 14:10, 9 July 2011 (UTC)

• Comment: To all those who say it isn't a proper noun—if that is the case shouldn't it be something encyclopedic like "DLL compatibility issues"? –CWenger (^ • @) 04:28, 15 July 2011 (UTC)

I think that you misunderstand what a proper noun is. If DLL hell referred to a specific event/place/trademark/etc. then it would be proper. Since DLL hell can occur to any Windows system, it defines a general state, hence it is not a proper noun.1exec1 (talk) 23:41, 15 July 2011 (UTC)

What is the difference between this and say, a make and model of car? I would say I have a Ford Mustang even though it is not a specific, unique item. Likewise, I would say I am in DLL Hell even though many other people could be there as well. –CWenger (^ • @) 01:22, 16 July 2011 (UTC)

The difference is that Ford Mustang is an unique model of a car, different from all other cars. DLL hell can be happen on any operating system that uses DLLs as shared libraries - Windows, Linux (through Wine), ReactOS. Thus DLL hell is not a proper noun.1exec1 (talk) 11:35, 16 July 2011 (UTC)

You're suggesting that if it only happened on Windows it would be a proper noun? It is a tough case, I agree, but I have never seen a non-encyclopedic name like this written as a common noun. As most (all?) sources treat it as a proper noun, I'm going to go with that. –CWenger (^ • @) 16:13, 16 July 2011 (UTC)

The above discussion is preserved as an archive of a requested move. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Solutions

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 FOOLIB.DLL, we would distribute FOOLIB_1_2.DLL, 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)

External links modified

Hello fellow Wikipedians,

I have just modified one external link on DLL Hell. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Added archive https://web.archive.org/web/20080703211550/http://dllcity.com/dll-hell.php to http://dllcity.com/dll-hell.php

When you have finished reviewing my changes, you may follow the instructions on the template below to fix any issues with the URLs.

This message was posted before February 2018. After February 2018, "External links modified" talk page sections are no longer generated or monitored by InternetArchiveBot. No special action is required regarding these talk page notices, other than regular verification using the archive tool instructions below. Editors have permission to delete these "External links modified" talk page sections if they want to de-clutter talk pages, but see the RfC before doing mass systematic removals. This message is updated dynamically through the template {{source check}} (last update: 18 January 2022).

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 00:16, 6 December 2017 (UTC)

Article is outdated and false at present

It's written and sounds like it applies to Windows 10/11/next however people have not had any issues with DLLs with modern x86/x86-64 applications in Windows since Windows Vista and Windows 11 doesn't even support 16bit applications any longer since it's 64bit only.

Someone has to update it to indicate it was an issue in the long past and it's not applicable to anything modern from Microsoft.

It's cited all over the web as if "DLL hell" is still a major issue plaguing Windows which is patently wrong/false. Artem S. Tashkinov (talk) 14:00, 18 January 2024 (UTC)