Let's wrap up the year with more on DLL conflicts and Windows 95B (InfoWorld)

December 23/December 30, 1996
Let's wrap up the year with more on DLL conflicts and Windows 95B
In this, my last column of 1996, I'd like to update two subjects that have caused a lot of reaction from readers during the past few months: conflicting versions of DLL files and Microsoft's policy of not selling Windows 95B directly to the public through stores.

Let's make a DLL
In a marathon series of four columns from Sept. 2 to Sept. 23, I wrote about conflicts among different versions of applications and different versions of DLL files.
Although I described some specific solutions, such as upgrading or downgrading certain DLLs, no universal fix is available. As I described in the series, some versions of Microsoft applications require older versions of some DLLs and don't work if those DLLs are replaced with newer versions (which many other applications innocently install).
This topic continues to dominate the mail I get. Many readers sent their own personal horror stories. Reader Neil Prestemon reported that a conflicting DLL doesn't even have to be installed to cause difficulty.
Prestemon explained: "Windows supposedly uses the following search order:
(1) A resource already loaded in memory;
(2) a DLL in the directory that an application was launched from;
(3) a DLL in the Windows directory;
(4) a DLL in the Windows\System directory;
(5) the current working directory; and
(6) the remaining directories in the path.
"I have found, however (the hard way), that Windows 95 will apparently skip Step 2 if the directory the application was launched from is on a CD-ROM," Prestemon continued. "This gets real troublesome if you are installing software from a CD-ROM and the setup program requires a specific DLL that's supposed to be in that directory and an older version is sitting in Windows or System."
Plain-old name conflicts still plague other Windows managers.
"The 16-bit MAPI.DLL and the 32-bit MAPI.DLL are named the same MAPI.DLL!" wrote Babu V. Sonti. "I was absolutely shocked, as I write applications for 16-bit mail systems and hopefully will be writing apps for the newly released GroupWise 5.0. I hope these folks all come together and come up with some standards."
Still no word from Microsoft on a foolproof solution to this quagmire.

Microsoft's Windows 95B
On Nov. 18 and Nov. 25, I wrote about Windows 95B, a new version of Windows with improved Display Properties, a NetMeeting application, and so on. I criticized Microsoft for offering Win95B only through hardware OEMs and for not supporting the new FAT-32 (file allocation table) file system. (The OEM from which you purchase a Win95B system is supposed to cover all technical support.)
I mentioned in one column that older defragmenters could corrupt a FAT-32 drive. But I haven't been able to find an example because FAT-32 is marked as a different partition type that older defraggers should leave alone. I regret the error.
A few users of Win95B reported that it is more stable for them than the previous version of Windows they were using. If so, it should be more widely available. If Microsoft doesn't want to support FAT-32, why not provide an easy upgrade to Win95B without necessarily converting a drive to FAT-32? Win95B works fine with the old FAT-16 system.
Well, even lowly columnists get to take Christmas week off. Look for me in 1997.

Brian Livingston is the co-author of Windows 95 Secrets Gold and four other Windows books (IDG Books). Send tips to brian_livingston@infoworld.com or fax: (206) 282-1248.
Missed a column? Go back for more.

Copyright © 1996 by InfoWorld Publishing Company

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