Readers offer ways vendors can deliver them from DLL hell (InfoWorld)

February 9, 1998
Readers offer ways vendors can deliver them from DLL hell
DLL hell occurs when one program disables others by installing an incompatible dynamic link library, or DLL, file. This corrupts your system in one of two ways. In the first instance, an application installs an older DLL over a newer one. This causes applications that require the newer DLL to fail. The second instance occurs when a newer DLL is properly installed but an application won't work with the newer version.
Microsoft's own applications can be the worst offenders. In my Jan. 5 column, I proposed a solution that Microsoft may implement. (See "Can Windows 98 provide some sort of solution to DLL hell?.") Windows should always preserve newer system DLLs. In those rare cases in which an application won't work with a newer DLL, a Control Panel applet could aid in swapping the two DLLs.
I invited readers to send in their solutions and got more than 100 proposals. Many contained good ideas that Microsoft could use to get us out of purgatory. The overwhelming sentiment among the proposers was that Microsoft should completely abandon the idea of having applications share DLLs at all.
"Application vendors should be prohibited from distributing parts of the OS with their applications," writes Kevin Klein of Millennium Partners. "It ought to be Microsoft's responsibility to provide a stable platform for running applications (that's what an OS is, after all). The whole Windows\System32 subdirectory should be write-protected to applications. All of the interim bug fixes and API upgrades should be packaged by Microsoft into clearly identifiable units, similar to the current service packs but with finer granularity, and released much more frequently."
Many readers said that all DLLs should be installed into applications' own folders.
"All application vendors, including Microsoft, should put DLLs, even `shared' ones like CTL3D32.DLL, in the home directory of the application, not in the Windows directory," says Thornton Rose. "Some of my favorite applications already do this -- WS_FTP, Programmer's File Editor, and WinZip."
If two applications require different versions of the same DLL, moving the correct version into each application's folder can sometimes cure the conflict.
One problem with this is that Windows does not allow two DLLs with the same name to run at the same time. This extends to the ActiveX controls used by Visual Basic (VB).
Mark Thrailkill writes, "Since Microsoft released VB 5 with newer versions of VB 4 controls without backward compatibility -- thereby creating the potential for the installation of VB 5 applications to disable VB 4 applications using the same controls -- do they care?"
A reader with the handle Jon B. has a solution for such conflicts: "In the illustrious Microsoft tradition, add a `thunk' to the DLL-handling routines (such as LoadLibrary and LoadModule). The thunk would check the Registry and redirect DLL calls to the correct version of the DLL. Of course, this implies that the kernel would be modified to manage (and allow) multiple versions of a given DLL simultaneously into memory." Unix, OS/2, and Apple's Rhapsody accomplish this kind of compatibility as a built-in feature.
In an interview last week, Windows 98 developer Shawn Stanford said Microsoft still hasn't chosen an approach to use to end DLL hell. Stay tuned.

Brian Livingston is the co-author of several best-selling Windows books, including the most recent Windows 95 Secrets (IDG Books). Send comments to brian_livingston@infoworld.com. Unfortunately, he cannot answer individual questions.
Missed a column? Go back for more.

Copyright © 1998 InfoWorld Media Group Inc.

InfoWorld.com complies with the ASME guidelines with IDG extensions For New media.