Talk:DLL Hell

message: 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)
thread_title:  Deleted paragraphs 

message: 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)
thread_title: Hyphen

message: 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)
thread_title: Category:Windows

message: 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)
replies: text: The title probably should be Dynamic Link Library Hell. Sam Tomato (talk) 18:19, 6 November 2014 (UTC)
thread_title:  Windows as the origin of the term 

message: 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)
thread_title:  DLL Hell and Unix 

message: 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)
replies: text: PJTraill 18:00, 12 March 2006 (UTC)

text: Rick Anderson (still at MS)Ricka0 04:14, 23 March 2006 (UTC)

text: Rick Anderson (still at MS)Ricka0 08:25, 25 March 2006 (UTC)

text: Sam Tomato (talk) 18:24, 6 November 2014 (UTC)
thread_title:  The article starts off wrong 

message: 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)
thread_title:  Lack info 

message: "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)
thread_title:  Dangling Modifier 

message: 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)
thread_title: Mac Extensions

message: 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)
thread_title:  DLL hell today 

message: 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)
thread_title:  "In Computing"? 

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

message: 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)
thread_title:  Windows-specific 

message: 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)
thread_title:  Underlying problem 

message: 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;
*....
</blockquote>
--Larry (talk) 18:14, 4 March 2008 (UTC)
thread_title: Causes

message: 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)
replies: text: 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)
thread_title:  Manifest hell 

message: 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)
thread_title:  Before when exactly? 

message: 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)
thread_title:  Solutions 

message: 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.
Cheers.—InternetArchiveBot (Report bug) 00:16, 6 December 2017 (UTC)
thread_title:  External links modified 

message: 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)
thread_title:  Article is outdated and false at present