What is DLL Hell?

Most of you have probably experienced DLL Hell, though you may not have heard of it described as such. If not, you've probably heard horror stories from friends or colleagues.

The story goes something like this:

Ring ring, ring ring...

"Good afternoon, SSW, Cameron speaking. How can I help?"
"Uhm, your program doesn't work on my system anymore."
"What seems to be the problem?"
"I don't know - it was working yesterday. There's no error message or anything - it just doesn't work."

Congratulations. You've just become another victim of DLL Hell.

What happened?

In a Word

"All it takes is a single DLL, VBX or OCX to be missing, or present in an older version... for an application to fail."

Most probably, another program installed an older DLL, VBX or ActiveX file on their system. OR maybe a newer, but incompatible version. OR a conflict due to an incompatible DLL already loaded in memory. OR the PATH environment setting changed. OR the file properly registered in the registry? OR a required file is missing?

Confused? So were we. As you can see, you can literally spend HOURS trying to figure out what is wrong with a customers machine, and why their applications will no longer run.

Background

Lets take a step back. In the old days, every application was self-contained. A program would (generally) consist of a single executable file. One thing was certain - the executables that accompanied a particular application could be used only by that application. Other products would NOT interfere with yours.

The Change

However, the Windows operating environment took advantage of a capability called dynamic linking to allow code modules to be shared by applications. The most important demonstration of the use of this capability is Windows itself - the code modules that contain the functions that make Windows work (the Windows API), are shared by all Windows applications. A code module that can be shared in this way is called a dynamic link library and normally has the extension .DLL.

What Happens?

It is not unusual for users to reinstall software - either during a system upgrade or to change configurations. In many cases users would install software that included an older version of a dll ie. commdlg.dll on a system that already contained a newer version. This would cause the more recently installed version to replace the newer version. As soon the user attempted to run the program that required the newer version, problems would occur ranging from operational difficulties to general protection faults.

The component-solution framework for programming has had one serious side effect concerning the distribution of Visual Basic applications. Now instead of a few DLLs that are shared by several applications, there are hundreds of DLLs, VBXs and OCXs that may be shared by literally thousands of applications. And all it takes is a single DLL, VBX or OCX to be missing, or present in an older version (or even an incompatible newer version), for an application to fail. A poorly designed installation program, user error, registration error or change in the user's PATH environment variable are a few of the ways in which this problem can occur.

The Solution

There are two possible ways of finding your way out of DLL Hell:

• Using a browser-based (Thin-Client) solution.

This approach means you only have to worry about one machine. Solve it once and you've solved it for everyone.

• .NET (I guess Microsoft heard these problems loud and clear)

.NET Frameworks XCOPY deployment solves the registration problem associated with COM. Taking full advantage of some of these features will require modifying existing COM components, but we believe that it will save a lot of heart-ache.

Note: Microsoft are not retiring COM. They're making COM much easier and more productive, at the same time enabling a totally new kind of softwareWeb services.