When is an Application not an Application?

Many of the software problems that people run into stem from the confusing nature of today’s Windows applications. Instead of consisting of one large chunk of code (as they generally used to do, and still in many cases do on the Mac), today’s software programs are actually made up of lots and lots of little pieces held together by an umbrella application. This umbrella app is typically the main program file you double-click on to get an application started. To confound matters further, these different pieces are often strewn across several different locations on your hard disk, which creates even more possibilities for errors or other breakdowns.

Many of these individual pieces are .DLLs, or Dynamic Link Libraries, which are chunks of program code that are called upon to perform various functions as you run an application. Another name for them is Application Extensions. Ideally, you never have to worry about these files—they just do their magic in the background while you do your work. And, when everything works right, that’s exactly what happens. If one of those files is deleted, changed or somehow corrupted, however, the application that uses them won’t work, and you’ll be in trouble.

Let me explain the installation process to give you an idea of the issues involved. When you install an application, what usually happens is that the installer creates a folder for your new program, copies some of the application’s pieces into there, copies other pieces into the Windows folder, creates shortcuts to your program on the Start Menu (or in the Program Manager for Windows 3.1), makes additions to the Windows Registry, and may even make some additions or alterations to your startup files, such as autoexec.bat, win.ini, etc. (In many cases, these changes are the cause of problems that keep your PC from booting properly. See the "PC Startup Troubleshooting Tips" article for more.)

The complexity of this process is the reason, by the way, that uninstaller applications were developed in the first place—it simply got to be too hard to keep track of where all the different pieces of an application were stored (if you could even get that info in the first place).

The files copied into the Windows folder may be .DLLs or they may be other files that the program’s developer has decided should be kept there. Unfortunately, so many developers have decided to store bits and pieces of their applications in the Windows folder that it’s become a dumping ground for a whole lot of junk. (Even worse, there’s no easy way to separate the wheat from the chaff—the useful, necessary stuff from the unneeded "bloatware"—so Windows folders just keep growing and growing….) Some of the .DLLs will probably be unique to the program you installed and will only be used by that application. Others will be shared files, which means they might be used by more than one application. And that’s where lots of problems arise.

Imagine, for example, that application A uses a shared .DLL called ABC.DLL. Now, let’s say that you install application B, which also happens to use the shared ABC.DLL. But, it turns out, application B uses a later version of ABC.DLL and so it overwrites the existing ABC.DLL file when it’s installed (without any warning to you). Now, depending on how application A is written, the next time it’s run and it looks for ABC.DLL, it may seamlessly work with the later version of ABC.DLL installed by application B, or it might crash (a likely possibility). If the latter occurs, it will undoubtedly lead you to wondering how that could’ve happened, since it worked just fine the day before. Sound familiar?

A similar type of situation is possible in reverse. Let’s say you try to remove application A from your system using Windows' Add/Remove Programs Control Panel (or even the application’s own uninstaller). At some point during that uninstall, the program may ask you if it should remove any shared .DLLs that are not being used by other applications. The default choice is to remove them and that's what most people do, but that can lead to more problems.

Again, depending on how the uninstaller works in conjunction with the application being removed, it’s possible that application A would remove ABC.DLL because it didn’t know that a newer version had been installed by application B and therefore would think that it wasn’t being used by another application. The result would be that after uninstalling application A, application B wouldn’t work because it was missing the ABC.DLL file (and you might even get an error message to that effect).

In both of these instances, the only real solution to these problems would be to reinstall the apps in question because there’s usually no simple way to reinstall only a shared .DLL (and even if there is, it may not be at all obvious where it needs to be located). In the first example, you’d probably have to first get an updated version of application A from the vendor’s web site and then reinstall that, hoping that it works with the new version of the ABC.DLL (and praying that it doesn’t add any new shared .DLLs that might break other applications!). In the second example, you’d just need to reinstall application B.