Designing Development Support Infrastructures (Part 4 of 5): The End of "DLL Hell": Supporting Centralized Corporate Development
- "DLL Hell"
- A Production Cycle Issue
- The End of DLL Hell
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Introduction
Every Windows programmer is familiar with the Dynamic Link Library (DLL) concept. Most have probably even lived through "DLL Hell.". It's the most common Windows problem. In fact, it's the problem that's at the source of several new Windows enhancements, especially in Windows 2000, and now in Windows XP. It's also at the base of Microsoft's new .NET Framework development initiative. But what is it in fact?
"DLL Hell"
Dynamic link libraries (DLLs) are essential Windows elements. A DLL contains the routines that can be called upon by a Windows program during its execution. In other words, a DLL is a library of functions with which a program can create dynamic links. In fact, DLLs are reusable components that are at the very core of the Windows programming concept. They can be used in different contexts. For example, Windows itself is a system composed of DLLs. The Windows DLLs offer system-wide services to other applications running on top of Windows. This includes how to talk to a printer, how to talk over the network, how to store information on a disk, how to display information on a screen, and so on. Windows programmers never need to worry about coding these particular functions; their applications only need to call the routines.
A Windows program is like an orchestra conductor or maestro, whose responsibility is to call upon the proper orchestra member at the proper time. In this case, orchestra members are DLLs. This approach offers great advantages. Since the program is a conductor, it doesn't load all of the components into memory when it's launched. Microsoft Word, for example, only launches its operating environment when a user double-clicks the Word icon. Then, as the user applies different functions, Word calls each function from disk and loads it into memory, often unloading other functions to do so.
This approach greatly simplifies programming by dividing it into smaller components; the programmer only needs to concentrate on a given function while coding it. This programming method fully supports the distributed programming model, making large software development undertakings easier to manage and break down. But it does have its drawbacks.
The biggest problem with the DLL model is the model itself and the people who use it. Let's take Word again as an example. When Microsoft prepares a new version of Word, they don't need to concern themselves with all the Windows functions that Word will call. Thus, the Word program or conductor will use both private DLLs that are particular to Word and that are delivered with the product, and public DLLs that are already included in Windows (see Figure 1).
)
Figure 1 The DLL concept in Windows.
"DLL Hell" occurs when, during the preparation of the software for market delivery, Windows software manufacturers decide to include public DLLs within their software assemblies. It's understandable. If a manufacturer has tested and retested their new application with a precise DLL kit (often amounting to a particular version of Windows), they will want to reproduce this version on destination systems by including all components in the system build. So, when you install the software on your system, it will automatically install system components that are most likely already on your system, just to make sure that the software manufacturer receives fewer support calls. The logic is sound from the manufacturer's point of view: "We know that our product works with such-and-such a version of a DLL, so we have to ship it with the system."
This logic is a lot less sound from your point of view, however, especially if you're an experienced Windows user and you always keep your system up to date by downloading and installing service packs and hot fixes from the Microsoft web site. In that case, it's most likely that the version of said component on your system is much more current than the version that comes with the software you just purchased. When you install this new software, your own version of the component is destroyed, often without any warning to you, the user.
That's DLL Hell. A working system is destabilized because software manufacturers constantly deliver software that includes public DLLs. The result: the famous Windows Blue Screen of Death!
Microsoft has come a long way toward a solution; Windows 2000 and Windows XP both include several features that aim to correct this problem. But why does the problem exist in the first place? Where does this need to include public DLLs come from? Is it only human nature?