End of Life Issues

Wow.  Yesterday I asked y'all when it was ok to end-of-life an API.

I'm astonished at the quality of the responses.  For real.

Almost everyone had great ideas about it - some were more practical than others but everyone had great ideas. 

Several people suggested a VM based solution, that's an interesting idea, but somewhat impractical with the current state of technology.  And it's beyond the scope of what I'm trying to discuss.  In particular, I was wondering what the criteria were for end-of-lifeing an API.  Also, Mike Dimmick pointed out one of the huge problems with VM solutions - it doesn't work for plug-ins.

A number of people talked about end-of-lifeing with the release of a new platform.  But the problem there is that the Windows appcompat contract is a BINARY contract, not a source level contract.  So we can't release a new version of Windows that doesn't support APIs, since that would break existing applications.

A couple of people suggested that open-source would be the solution to the problem.  But open sourcing old APIs that doesn't fix the problem, it just pushes it onto someone else.  And by releasing the source to a high level API, it locks down the interface in at a lower level, which is almost always a bad idea (because it removes your architectural flexibility - what happens if there are four different APIs that use a single low level API, you want to end-of-life one of them but keep the other three.  If you open source that one, then you freeze the low level API, which removes your ability to innovate the other three APIs (this is a grotesque simplification of the issues, I may write more on this one later).

Michael Kaplan wrote about a possible solution, but that doesn't really solve how you REMOVE APIs - it just describes how you can make changes without removing the APIs.

At least one person said that the software wasn't relevant that it was the data that mattered.  At some level, that's right, but it's a naive view of the world - the reality is that for most businesses, if their line-of-business application doesn't work, they don't care if their data hasn't been lost - their business is still just as shut down.  And many businesses DON'T have the source for their LoB applications.  Or they don't have the money to bring those applications up-to-date.  It can cost millions and millions of dollars to update a suite of LoB applications.  And those updates invariably involve UI changes, which means retraining costs.  Which most businesses aren't willing to take on.  So the existing apps have to continue to run.

Dana Epp was one of the first people to pick up on what I think is the most critical aspect of end-of-lifeing an API - you need to have a credible alternative to the API - one that offers comparable functionality with similar ease of use.  If you don't have an easy alternative for customers to adopt, then they won't adopt it.

But (IMHO) the most important thing that everyone missed (although Dana came close) has to do with the binary contract.  You must keep existing binaries working.

And that means that your ONLY opportunity for removing an API comes when you know that every application running on your system is going to be recompiled.  That happens when you switch hardware platforms.  So there have really only been three opportunities in the life of Win32 to do this - Alpha, PPC, X64.

Any other time has the possibility of breaking applications.

So to me, an API can be removed if:

  1. You can guarantee that there are no existing applications that call the API.
  2. You have a credible alternative API that is comparably easy to use.

Criteria 1 only occurs with the release of a new hardware platform, Criteria 2 is just a result of careful planning.

While I was doing the "How to play a CD" series, Drew noticed that my sample didn't work on his version of x64.  Why?

Well, because we thought we could end-of-life the MCI APIs for x64.  It turns out that virtually all of the MCI API set has been replaced with newer, more functional APIs and there were some architectural issues with the MCI APIs that made it attractive to remove them.  So we did.

And then we realized that we'd messed up.  Why?  Audio CD playback.

It turns out that we didn't have a reasonable alternative to the MCI APIs for CD playback - everything else had credible replacements but not CD playback.  And it turns out that a number of apps that were being ported to x64 relied on the MCI APIs for CD audio playback.

So we put all the MCI APIs back before we released, and addressed the architectural issues.  Because appcompat trumps architecture every time.

Having said that, a number of the people making comments were absolutely right - for Longhorn, there WILL be some scenarios that won't continue to work, as a result of some of the high level architectural changes we're making.  But we're being a lot more careful about ensuring that those scenarios truly ARE corner cases.

Having said all this stuff about when it's ok to end-of-life code, I MUST include Adrian's comment verbatim:

A lot of the comments here are looking at this from the point of view of somebody with existing applications upgrading to a newer version of the OS. It's an an important considertation, but it's not the one I am faced with day to day.

As developers, we rarely get to choose which platforms we target. The market determines that. I and many other Windows developers I know are building *new* applications, but the market demands that they run on older platforms as well as the "current" ones. A non-trivial number of people still run Windows 98 and NT 4, especially as you look at the international market.

The users of an obsolete API are not necessarily applications that are five or ten years old. They may be brand new applications that rely on an API that was been superceded long ago because it's available across all of the platforms that must be supported.

Sure, sometimes your application will dynamically use a newer, better API if it's available or fall back to the old one if it's not. But when the old API is sufficient and universal, it will often be used rather than the "current" one, even in sparkling new code.

Consider Avalon, a whole new presentation layer. How long will it take for it to completely replace GDI? If I'm writing a new general-purpose application today, I *have* to use GDI. Even if I were targeting a release date that coincides with Longhorn, I couldn't afford to ignore Windows XP, Windows 2000, Windows NT 4.0, Windows Me, and Windows 98. (In reality, we even ensure that the basic functionality of our app works even in Windows 95 and NT 3.1.) If I had unlimited resources, I *might* try to develop a parallel GDI/Avalon version. But when is the last time you were on a development project with unlimited resources?

I don't have a general answer to Larry's question, but using GDI as an example, I'd say you could retire it when Longhorn (or perhaps XP with Avalon extensions) is used about as much as Windows 98 is used today. That's probably four releases after Longhorn, or more than a decade away.

Adrian's spot-on - it's not enough that we ensure that the API has been superseded.  We also need to ensure that the replacement either is available on previous platforms or has been around for enough time that it it's a credible alternative.