Windows Confidential
Compatibility Constraints
Raymond Chen
WHEN YOU THINK of a new version of Windows® maintaining backwards compatibility with applications designed for previous versions of Windows, you tend to think of the explicit programming contract: things like the behavior of window messages, the semantics of the heap, and that GetTextMetrics will get the text metrics. But that's the easy part of maintaining compatibility, since those rules are actually written down. The hard part is maintaining compatibility with the things that merely happen. Some behaviors are not contractual, and often they aren't even designed—they just happen by circumstance.
The Windows Shell team recently came across an application that wanted to map a network drive when the user clicked the corresponding toolbar button. But to do this, the application's developers didn't call the WNetConnectionDialog1 function. Instead, they decided to create a context menu on the My Computer object and then invoke the Map Network Drive command from the menu, which in turn calls the WNetConnectionDialog1 function. In other words, the application's developers avoided the documented function and relied on a middle man to do this work for them. This middle man, I should point out, is under no contractual obligation to have a Map Network Drive command in the future.
But it gets better. The developers didn't write the program to invoke the Map Network Drive command. Rather, they observed that the command was always the third item on the menu and, therefore, simply had the application invoke item three.
But what about context menu extensions, such as Add to Playlist? Since all of these extensions are typically added near the top of the menu, the developers adjusted their algorithm: instead of executing the third item on the menu, they executed the fifth-from-the-bottom menu item.
But wait, it gets better still. They also noticed that the Map Network Drive menu option had a different position on Windows 2000 than on Windows XP. So before invoking the command, the application checks which operating system it is running on and adjusts the computations accordingly.
For Windows Vista™, we did some work to clean up the context menus, removing commands that are redundant and moving rarely used commands to the extended menu. (In case you're wondering, you reach the extended menu by holding the shift key when right-clicking the item.) After we cleaned up the menus, this program (not surprisingly) ended up executing some other command instead of the one it wanted, thanks to the reordering of menu items.
Some people may argue that Microsoft should leave the program broken as a form of punishment. But then who would really be getting punished? The customers who were using this program would be stuck until the vendor produces an upgrade that fixes the problem. They would lose the use of the program for a few months ("sorry, but you missed the contract bid deadline while you were out of commission") and then they may even have to shell out some cash for an upgrade that fixes the problem. The customer suffers lost productivity; the vendor gets upgrade revenue.
Looks like the vendor wins and the customer loses. (Not to mention that many users would probably blame the new version of Windows for breaking a program that ran perfectly fine in the first place.)
What's more, this program is a competitor to a Microsoft product. The conspiracy theorists would once again be apoplectic with glee, posting articles to blogs about how "Windows Vista intentionally cripples competing software in order to give Microsoft an unfair advantage." In the world of Windows, it sometimes feels like everything is a compatibility constraint
Raymond Chen's Web site, blogs.msdn.com/oldnewthing, deals with Windows history and Win32 programming. He also loves what you've done with your hair.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.