DLL Hell

DLL Hell is the clever (almost rhyming) name given to the array of malfunctions caused by version mismatches between shared libraries on any Microsoftish operating system.

The above statement could be frightening to the uninitiated, so I'll slow down a bit. DLL stands for dynamic link library, which is IBM/Microsoft-ese for shared library. A DLL, like a shared library on any platform, is a lump o' program. Programs are distributed as executable files; that is, the program you run. Most executable files have a lot of overlap in their needs, and rather than reproduce the same code in each executable, the relevant parts are moved into a separate file, which is shared between all applications that need it. This is the shared library.

On any of the operating systems where DLLs are prevalent (mainly being the Windows family and OS/2), large portions of important operating system code exist in DLLs. So, if a program wants to show a "File Open" dialog box, change the video mode, allocate memory, or rename a file, it just calls a routine in an operating system DLL.

The idea is that because the application code and the library code exist in separate files, they can be upgraded independently. What fun! Theoretically, all you'll need to do is upgrade a few system DLLs, and all your applications will have fabulous new features. However, this does not work.

For example, COMDLG32.DLL is popular DLL that is responsible for several Common Dialog boxes on the 32-bit Windows operating systems, including File Open, File Save, and Select Color. Early in the release of Windows 95, there were at least three versions of this file floating around: the one released with Windows 95, the one released with Plus!, and one silently installed with Microsoft Office. The problem, and a serious case of DLL Hell, arose because each of these versions had subtle undocumented differences, and the existing documentation was not specific enough to determine the right way to use them. As a result, a program using COMDLG32.DLL that was developed with one version may be running with a different version, and as a result not function correctly. The errors are sometimes obvious (GPF) and sometimes not-so-obvious (failed file save with no error message). To make matters worse, it isn't trivial to determine which version you had: if you installed, but then removed, Mircosoft Office, its stealthy COMDLG32.DLL would still be on your system. This kind of DLL Hell is a result of bad implementation on Microsoft's part, exacerbated by slipshod upgrades: if they obeyed their own standards, the various COMDLG32.DLLs would have been interchangable. (Then again, there are those who argue that this particular instance of DLL Hell was an intentional play by Microsoft to cripple its competitors.)

Another flavor of DLL Hell arose in Windows 3.1, before a socket networking interface became part of the operating system. Sockets were implemented through WinSock, which served as glue between the network protocol and the application. WinSock was distributed as a DLL. The problem was that each ISP, including AOL, provided their own version of WinSock. If you wanted to connect to a different service provider, you would need to exit Windows, copy the appropriate WinSock DLL into your Windows directory, and restart Windows. God save the man who uses the wrong version of WinSock or accidentally overwrites the appropriate version.

Many of the reforms in Microsoft's .NET strategy attempt to solve DLL Hell. For example, .NET records in the application file which particular version of a DLL it expects. Also, multiple versions of the same DLL are allowed on the same system, and there is an intelligent search algorithm to find the correct one.

The worst part of the problem with Dll Hell is that there is no simple way to understand why your program is not working. You may install a game you found on the net and after a while realize that something else is not working. As the problem is related to shared components, what breaks is always "something else" so it's not trivial to detect what broke what. Even if it were possible, the uninstaller would in all likelihood use a conservative approach and not try to remove shared components (probably dumped in some system directory), so the problem will stay even after the culprit's gone.

Windows system have no user comprehensible way to detect what went wrong and where if so-called DLL early binding is in use (no "method xxx() not found in version yyy of zzz.dll, please upgrade to yyy+1" error popping up), and the tradition with Windows error handling is to hide error reasons away from the user. If you happen to develop a project with a large number of DLL involved, the problem rises very quickly and it's very hard to trace and solve: a wrong DLL copied on a production machine can break a system and take hours to understand what went wrong.

If this is not enough for you, you should remember that a COM DLL has to be "registered", i.e. the system registry must be notified a DLL is present. Deciding whether a DLL is already present on a given machine is again a non trivial task unless you want to spend hours playing with RegEdit and RegSvr32, and previous instances of a given DLL must be "unregistered" even if they have already been removed. And even if you do all this right and unregister everything before registering it again, the process may break for no apparent reason and you have to clean the registry manually or reinstall the whole machine.

Dulcis in fundo, not only DLLs are causes of DLL Hell: even OCXs (visual controls put on pages, like text fields or combo boxes) and registrable applications (thing that look like a standard .exe but require a registry update to run) behave in the same exact way. That's why if you keep on loading different software from different vendors on yor Win32 machine, sooner or later you'll have to reinstall.

Please note that not every program developed for the Win32 platform has to use registered DLLs to run: for instance to run a program as complex as Mozilla Firebird you simply copy a folder on your machine and double click on the main program icon, and the same goes for Opera. It is more a matter of software design than need.