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 February 11 column, I proposed a solution that Microsoft may implement. 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," wrote 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," said reader Thornton Rose. "Some of my favourite 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 wrote: "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?"
Another reader Jon Bunson 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 a recent interview, Windows 98 developer Shawn Stanford said Microsoft still hasn't chosen an approach to use to end DLL hell. Stay tuned.
BUGS & FIXES
Microsoft's Internet Information Server
Beware of trying to run a multi-thread Java application on Microsoft Internet Information Server 3.0 on a multiprocessor computer. Microsoft officials said the Java application may lock up because the internal Java virtual machine thread-manipulation function is not multi-thread safe. Microsoft is currently testing a fix, which will be available in the next service pack.
Netscape Communications' Enterprise ServerIn the various Unix flavours of Version 3.01, something has been left out on the page that changes the log file. To fix it, edit the file called lgaccess.html that is in the bin/https /admin/html directory under your server root. First, save a backup copy named something else, like lgaold.html. Then find the line that says (!-- SUBMIT --) and add the following line just before it (input type= "hidden" name="no_format_str" value="0").
After you save the file, reload the Log Preferences page in the Admin server.
When upgrading from Version 2.1 to Version 2.5, if you try to load Management Agents using NMA2.NCF, you may get an error message that the evaluation period has ended. This happens if an additional licence for ManageWise is stacked onto an existing one while installing and upgrading. Novell says to unload MWISE.NLM and load it again to fix the problem.
Found a bug? Tell the forum at forums.infoworld. com/cgi-bin/displayForums.pl?/forums.htm.
For more bug reports, browse to www.bugnet.com, or send e-mail to firstname.lastname@example.org