Every so often, even the best of us are tempted to grab our computers—this works best with expensive machines—and hurl them out the nearest window. Open or closed, your choice. The urge is strongest when you've installed a new piece of software that "breaks" your existing programs. They refuse to load, load slowly, or worse, cause your system to crash. It's common, but it can be maddening.

Before you head for a window, know that problems like these are symptoms of a DLL (dynamic- link library) conflict. A DLL is a file that shares code among multiple programs. Most of the time, the sharing goes off without a hitch. But after you install a program, remove a program, upgrade or patch your system, a problem with DLLs can grind your machine to a halt. To fix it, you'll need a working knowledge of Win98's version data for DLLs and the basics of their management.

Nuts & Bolts

In the Jurassic age of computing (before Windows), programs such as spreadsheets and games were fully self-contained in a single EXE (executable) file, the executable. All of the code the program needed to work, including its bells and whistles, was stored in a single file on the hard drive, placed there at setup.

This "one program, one file" method had its perks. First and foremost was simplicity: It made the hard drive a clean, neat, and orderly place, much to the delight of Martha Stewart. And it helped with stability, as well: A system with 1,000 files is inherently more stable than a system with 10,000 files. But there were problems, as well. Because programs were kept from sharing code, their designers were forced to reinvent the wheel with each new program they built. Even the simplest functions, such as saving or printing a file, had to be written from scratch for a new piece of software.

The rise of Windows encouraged a new concept in programming, known as dynamic linking. Linking lets programs share blocks of code with common functions, such as saving or printing, by storing the code in special files that can be called on (or linked to) by the programs that need them. These files are DLLs, and they store the vast majority of Windows' features. What's more, they also save space (at a premium in the early days of Windows) and double the ease and efficiency of writing code.

DLLs are one of three types of files used to share code among programs. The other two are ActiveX controls (objects, such as special drop-down menus, that can be automatically downloaded and executed in a Web browser) and VBX files (VBX is short for Visual Basic Control, software meant to be shared by programs written in Visual Basic, a common language in Windows). To get a sense of the hundreds (indeed, thousands) of such files on your system, click Start, Programs, Windows Explorer. Click the plus sign (+) next to the C: drive to expand its contents and click Windows, System. You're now in the heart of your system, where most of its crucial files are stored. (Hence, be careful not to delete one by accident.) Click View, Details to show your files in a detailed list and then click the Type bar at the top of the list to sort the files by type. Scroll down to find the files marked Application Extension. These are your DLLs.

The Problem

How can something so vital—namely, the DLLs that give your software its richness of features—give your system fits, as well? When you install a program, patch a program, or upgrade the system, the setup feature can replace a good DLL with a file that has botched or bungled code. It can overwrite a current DLL with an old version that no longer works. Or it can erase a DLL altogether. (This is all too common when you remove a program you no longer need.) As a result, the programs you keep will stop working, start to work slowly, or cause the system to crash. It's called "DLL Hell."

You'll need to know the symptoms of a DLL conflict to identify and solve it. First and foremost, if the addition or removal of a program stops an old program from loading, it's a dead giveaway that a DLL is to blame. If a program loads but won't open its basic features, such as the Save As dialog box, it's safe to assume the DLL that stores that bit of code has been damaged. A GPF (General Protection Fault), which often leads to the Blue Screen of Death, is often caused when a crucial DLL has been moved or renamed. And last, of course, is an error message that mentions a DLL by name. In that case, you not only know the cause, but you also know which file to fix.

Version Control

Problems with DLLs are so common (and so vexing) that Win98 tracks their versions to combat the issue. Along with lines of code and data, files contain their own version information, known as metadata. A file in version 3.2.1, for example, is the first release of the second draft of the third version. (To err is human; to err often is the right of programmers.) When you add a program to your system, the setup feature will test the files it copies to your hard drive against the files that are already there. If one of those files is newer than a file with the same name of the one that's about to be copied, setup leaves the file alone, moving on to install the rest of the software. By and large, this keeps a program from loading an old DLL over a current one.

In spite of this, DLLs are often replaced or erased by new files in the course of an installation, removal, patch, or upgrade. When it happens and your system gets the jitters, you'll need to determine the version of the DLL in question. Open Windows Explorer (Start, Programs, Windows Explorer). Click C:, Windows, System, where most of your system's DLLs are stored. (Note that others are stored in C:\PROGRAM FILES, but these are less likely to be shared by multiple programs and thus are less likely to cause a problem.) In the menu bar, click View, Details. Right-click a DLL, and choose Properties. Now click the Version tab. (Every so often, you'll find a DLL with no version information, but it's rare.) You'll see the file's version, a brief description of its contents, and its copyright information. In the Item Name list, you'll see other information, such as Company, Internal Language, Legal Trademarks, Original File Name, Product Name, Product Version and so on. The file version itself, as we'll see below, is crucial to fixing your system's problem.

The Fix

If you suspect an old or faulty DLL is the cause of your system's hiccup, you can replace it with a current version. Let's say your copy of Microsoft Outlook won't open and tells you that MAPI32.dll is to blame. You'll see an error message to this effect when you try to boot Outlook. In fact, this is a common problem for users of Eudora and other email software, which can rename the DLL as MAPI32.000 during setup, causing Outlook to fail.

To fix the problem, copy a current version of the DLL from the Office CD or Microsoft's support site at http://support.microsoft.com. Use the instructions above to compare the version of your DLL with the DLL you intend to replace it with, making sure the second is the newer of the two. If it is, paste it to the same location as the original DLL on your hard drive (here, C:\WINDOWS\SYSTEM), then reboot your machine. When you reach the Desktop, open Microsoft Outlook to send and receive email.

When there's no error message to let you know which DLL is causing the trouble, you can remove the software you just installed (the one that caused all the trouble) and reinstall the software you'd like to use. For example, if a new piece of shareware leaves you without a working copy of Photoshop, click Start, Settings, Control Panel, Add/Remove Programs. Choose the shareware you'd like to remove and click Remove. You'll be asked to reboot the system in order to remove any files that were still in use when Add/Remove Programs tried to delete them. (Files in use can't be deleted.)

When you're back at the Desktop, run the Photoshop setup again. True, this is a tedious fix, but it rarely fails. By reinstalling Photoshop, you copy the full set of DLLs it needs to run from your hard drive.

by David Garrett