One of the biggest headaches for users of Windows 95 -- especially corporations with hundreds or thousands of PCs -- is that the installation of one Windows application can write over "shared" files used by other applications.
This causes the more unfortunate applications (which worked fine before) to crash when they can't find the file they're after.
This problem affects several types of files, including dynamic link libraries or DLLs, and is therefore referred to as "DLL hell".
I wrote a series of four columns documenting this problem back in September 1996 (to read these columns, go to www.infoworld.com/printlinks). This series showed that a high percentage of Windows 95 crashes could be attributed to DLL conflicts. A conflict occurs when an older DLL has been written over a more current one, but the change is not enough to make Windows totally unusable. Only when an application tries to run a specific function in an affected library -- and the function doesn't work in the older version -- do you experience a crash. Hitting that specific function can be maddeningly random, making troubleshooting difficult.
DLL hell could be avoided if all applications bothered to check the internal version number of shared DLLs before writing over them. Unlike the file date, which can easily be changed, most DLLs contain an internal version number that is reliable and can be read by installation programs.
Unfortunately, there are scores of programs that don't follow the rules. Even Microsoft applications have been offenders. Specifically, Microsoft Office 4, Excel 5, Word 6 and other Office packages actually required older DLLs instead of the newer versions available from Microsoft. For example, Office 4.3c could use a file called OLE2NLS.DLL, Version 2.01, but not the same file in Version 2.02. If you wanted to install applications that needed the newer version and you also wanted to use Office, you faced a major problem.
I'm glad to say that a solution to DLL hell might be on the way. I attended an invitation-only briefing late last year for six journalists in Redmond, to see the latest build of Windows 98. New tools are becoming available that could put an end to DLL hell once and for all.
Based on ideas from the briefing, this is the way I envision protection from DLL conflicts to work: If an ill-behaved application tries to write an older, shared DLL over a newer one, Windows detects the attempt. Windows moves the newer DLL out of harm's way, then allows the application to install the DLL it wants. (Refusing to allow the DLL to be installed would make it impossible to install the application at all, even though it may work OK in all other respects.)After the application has completed its setup routine, Windows moves the older DLL to a neutral location and moves the newer DLL back into its original position.
In 99 out of 100 cases, the application with the ill-behaved setup routine works with the newer DLL.
Everyone is happy and the user doesn't even need to know that Windows averted a major opportunity for disaster.
In the 1 per cent of cases in which the new application won't run with the newer DLL, Windows 98 will provide a system configuration utility that can move DLLs to proper locations, replace one with another, and so forth.
The Beta 3 of Windows 98, alas, doesn't exhibit the behaviour described above. Instead, if Windows 98 detects a newer DLL being overwritten by an older one, it allows it to happen but makes an entry about the event in the system configuration utility.
It is far too late to do much about a problem that can render multiple Windows applications unusable.
I hope Microsoft will switch the default behaviour so it protects the "good" DLLs from the "bad" DLLs that might replace them.
Send me your alternative solutions, with "DLL hell" as the e-mail subject, and I'll pass them along to Microsoft.
Brian Livingston is the co-author of several best-selling Windows books, including the most recent, Windows 95 Secrets (IDG Books). Send tips to email@example.comHe regrets that he cannot answer individual questions.