Is it really true that nobody likes change? Not reall. I think the main reason for doing what Microsoft have done, as described in Michael’s post “Nobody likes change,” is because people actually do like change (as long as it’s for the better) but people also work in a world where users are still running Windows 95, years after its support has been discontinued.
Especially when you’re talking about a very simple API that is either entirely algorithmic in nature (like the IDN mitigation APIs mostly are), or is a simple table-driven data-provider (like these new APIs are), there’s no reason for it not to be included in downlevel versions of the operating system.
Obviously, you need to provide some incentive for people to upgrade, but what you need to remember is that you have to encourage users to upgrade, not developers, but you do need to encourage developers to develop for the new platform. It’s a bit chicken-and-egg, but providing downlevel versions of some APIs is a good way to get developers to look at the newer features.
One point Michael makes is that:
[T]o make developers willing to accept change, you need to provide all the following:
- A good reason to make it
- An easy way to do it
- It has to work on more than just the latest version
Now, I would agree with the first two, but I would somewhat disagree with the last point. As long as the first two are true, the second is not necessarily true. Take these new APIs for instance. Currently on Windows XP these is no way to get this data, without including the tables in your own code. This means that if you want this functionality, you would need to do all of the work to include the tables anyway – there’s not much incentive to put in an “if (running-on-Vista) { do-it-the-Vista-way }” block into your code.
However, if you’re (for example) writing a Wizard, then it might make sense to develop two separate user-interfaces. One using the classic Wizard97 look-and-feel for Windows 2000, XP, etc. And another using the new Aero Wizard look-and-feel in Vista. Now, theoretically, it might be possible to do this by simply changing the flags on Vista, but in reality, you’ll probably want to go through and change your radio-buttons into the new “command links” controls to make it more Vista-like.
You could probably even go so far as to design your Vista-only wizards and then programmatically convert them to Wizard97 wizards in code (by replacing “command links” with radio buttons and whatnot) when running on downlevel platforms.
The point is that if it’s possible to do a “similar but less-efficient” or “similar but not-as-good-looking” version of the same in downlevel platforms, then you can just include your changes in the newest version. Developers can then choose to implement both versions if they like. But if you’re providing functionality which you’d have to implement from scratch on the downlevel platform (like this LCIDToLocaleName stuff) then a downlevel API makes sense, in order to encourage developers to actually use it (and not simply implement it from scratch).