Windows ConfidentialShare and Share Alike

Raymond Chen

Have you ever wondered why it is that when you uninstall a program, Windows® asks whether it should delete a file that "may prevent other applications from running correctly"? First of all, that message (featured in the screenshot) is not coming from Windows—it's coming from the uninstaller. The correct question, therefore, is really, "Why does the application uninstaller display this dialog box?" This is an excellent example of asking a user a question that he can't answer. What led to this sad state of affairs?

To manage reference counts for files used by more than one application (such as the MFC runtime libraries, which are used by multiple unrelated programs), the installer creates an entry under the SharedDLLs registry key. This entry lists the file and its reference count. If there is already an entry for the file, the reference count is incremented. And if the entry doesn't yet exist, the reference count is set to one. Conversely, when the program is uninstalled, the reference count is decremented, and when it drops to 0, the file is deleted because there are no programs that are using it anymore. At least that was the theory.

Should I delete it or not?  (Click the image for a larger view)

A serious problem with this model is that it assumes everybody agrees to play by the rules. But the temptation to cheat is enormous, since the consequences of cheating typically do not penalize the cheater.

For example, say there is a program that uses the MFC runtime libraries, whose installer just copies these libraries into the system directory without updating the reference count. Then, when this program is uninstalled, it merely deletes the libraries. Now consider what happens when this program attempts to coexist with a program that follows the rules. Here is the basic turn of events:

1. Install Good Program: the libraries are installed and the reference count is set to 1.
2. Install Bad Program: the libraries are installed, but the reference count is unchanged.
3. Uninstall Bad Program: the libraries are deleted.

The result of these events is the Good Program stops working because the libraries are now gone.

Here's another scenario:

1. Install Good Program: the libraries are installed and the reference count is set to 1.
2. Install Bad Program: the libraries are installed but the reference count is unchanged.
3. Uninstall Good Program: the reference count drops to zero and the libraries are deleted.

The result of this scenario is the Bad Program stops working.

The people who wrote the Good Program figured, "Well, we can't stop the Bad Program from hosing us, but at least we can try to stop ourselves from hosing the Bad Program." Therefore, when they're about to delete a file, they stop and display a warning message saying, "Oh boy oh boy oh boy, I'm about to delete a file, OK? If there's a Bad Program out there that's still using it, then that Bad Program will be hosed. If you have a Bad Program, then you should click Don't delete." OK, that's not the exact phrasing, but you know what dialog I'm talking about. Even the legendary Jeffrey Richter recommended this approach in a 1996 Microsoft Systems Journal article.

Unfortunately, by doing this the user is presented with a question he has no chance of answering correctly.

Of course, all those control freaks who demand that Windows give them the option of overriding every last thing should be applauding this dialog box. The uninstaller programs of the world are giving you file-by-file control over the uninstall process. So be careful what you ask for—you just might get it.

Raymond Chen's Web site, The Old New Thing, and identically titled book deal with Windows history and Win32 programming. He wonders whether nuclear fusion will become viable in his lifetime.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.