TechNet Magazine > Home > Issues > 2006 > November >  Windows Confidential: Handling Compatibility Ha...
Windows Confidential Handling Compatibility Hacks
Raymond Chen

THERE WAS A PROGRAM written for Windows® 3.1 that opened the Printers Control Panel by looking for the Control Panel window, accessing the File menu, and searching for an item called Printer. In Windows 95, the Control Panel didn't have a Printer option under File. As a result, when run on Windows 95, this program would post a garbage command message to the Control Panel. To address this problem, Windows 95 created a decoy Control Panel window for the program to find. When the program posted the message to the decoy, the Printers folder opened.
Some people argue that Windows 3.1 should have detected that the program was making bad assumptions about the Control Panel and displayed a warning. That way, the author of the program would have seen the warning and fixed the problem before releasing the product. But detecting the intent of a chunk of code requires a degree of analysis that ventures into the realm of artificial intelligence. Essentially, Windows 3.1 would have had to detect that the program was doing a strcmp for Printers, analyze the particular strcmp, and decide if it were bad. But that only catches the Printers case. How many compatibility checks do you want the system to perform? And what about false positives?
Another argument is that Windows 95 should have responded to this bad assumption with a warning dialog that said "Program XYZ is doing something bad." But for Control Panel to know what posted the garbage message, the detection would have to be put into the window manager. This creates a fragile coupling between two components-Control Panel and the window manager. And, again, this only addresses one case. Do you want the window manager to be brittlely coupled to all the other components in the system?
Providing a generic message, without naming the specific application would be easier. But that's not a good solution, either. A vague error message is no better than no error message at all. What's more, this dialog would in all likelihood be ignored by the user-especially since it wouldn't recommend a specific course of action. Users would perceive the dialog box as an annoyance. This is a very important point. It is essential that any error message be actionable. If the user knows how to react to the warning, the dialog becomes useful.
Another problem is that a dialog box creates a point of reentrancy due to the dialog loop. This is a technical problem. Unexpected reentrancy is a major source of bugs in UI programming. What's more, the Control Panel itself may be in a modal state and displaying a dialog box causes the modal structure to fall apart.
A dialog box also creates a new localization burden. If a dialog box is written for every compatibility hack, there will be hundreds of them scattered throughout the system. Each would have to be translated into the 33 languages for which Windows provides full translations.
Finally, consider the reaction from competitors when their product results in one of these dialog boxes. They'd say things like "Microsoft is blaming other people for its own buggy operating system" and "Microsoft is intentionally making our program look bad." I'm not exaggerating. There have been companies who complained to Congress that Microsoft was maliciously targeting and disabling their software. Upon further inspection, it was found that there were bugs in their programs. Frankly, it's better just to fix their bug for them than endure a lengthy Congressional investigation.
As a result, the current versions of Windows only display a warning dialog when a program is so incompatible with Windows that it cannot run at all or that it runs with severe limitations. And even in that case, Microsoft tries to work with the vendor to ensure that no customer is left stranded. After all, people want to run programs on the operating systems they buy. If a program doesn't work, you don't care whose fault it is-you just want to get your work done.

Raymond Chen's Web site, The Old New Thing, deals with Windows history and Win32 programming. He is working on a book, coincidentally also titled The Old New Thing (Addison-Wesley, 2007).
Page view tracker