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.

Comments

• Anonymous
  May 12, 2005
  Actually this brought to mind the MS layer for unicode. Could you pull something like this off? It seems like the very situation that Adrian mentioned with APIs (which seems blatently obvious once you read it. But alas..) is the one that was encountered with Unicode, since the Win9x platform wasn't natively unicode. If there are, in fact, viable alternatives, it seems that there could be a layer that would do this conversion. For exes already linked, you could have shimeng catch the imports and patch in the layer automagically. Then the exes work on the old, and the new, and the functionality of the old code is only in the new place - but just redirected from several, not duplicated.
  
  Thoughts?

• Anonymous
  May 12, 2005
  This is what I get for doing many things at once.
  That wasn't clear at all.
  
  On the old machines, you have a layer to support conversion from new to old.
  
  On the new machines, you have a layer to support old to new.
  
  So on the old machines, new applications still run.
  
  And on the new machines, old applications still run.
  
  The question is whether all that work is actually worth it.

• Anonymous
  May 12, 2005
  Which API are you talking about? The kernel one, or one of the libraries?
  
  If it's just a library, I don't see the problem. Just bump up the version major number. People using the new API make sure they are linking against say foo2.0 and all the old apps linked against foo1.0 still work. Eventually when enough time has passed you just don't install foo1.0 by default anymore,and if someone really needs it they can download it as an option.
  
  This is more or less the way things work in Linux distributions.

• Anonymous
  May 12, 2005
  The comment has been removed

• Anonymous
  May 12, 2005
  The comment has been removed

• Anonymous
  May 12, 2005
  The comment has been removed

• Anonymous
  May 12, 2005
  When the DOS 1.x FCB functions stopped working on FAT32 drives in Win9x, was that a deliberate attempt to End-of-Life them or an oversight? The fact that they weren't removed from the NT-based OSes suggests the latter.

• Anonymous
  May 12, 2005
  "So there have really only been three opportunities in the life of Win32 to do this - Alpha, PPC, X64."
  
  X64 is actually a Win64 system - its the change to a new ABI that matters as much as the hardware platform.
  
  Oh, and you forgot both of the IA64 users :-)

• Anonymous
  May 13, 2005
  What is this "Windows appcompat contract"? I mean, I think everyone understands it in a way ... appcompat trumps architecture. But is there more to it? A legal thing? Is it spelled out somewhere?

• Anonymous
  May 13, 2005
  There's no contract.
  
  AndyM: Your're right, I had forgotten ia64, since ia64 and x64 came at the same time, I tend to lump them together, although they are very different platforms.

• Anonymous
  May 13, 2005
  The comment has been removed

• Anonymous
  May 13, 2005
  Would it be possible to release a version of Windows that specifically states that no backwards compatibility before X (where X may be Win95, 98,2000, or whatever is decided) is supported, for those users that prefer a cleaner install over the ability to use miscellanious archaic programs? This would not be ideal for everyone, but power users would probably appreciate the boost.

• Anonymous
  May 13, 2005
  The comment has been removed

• Anonymous
  May 13, 2005
  The comment has been removed

• Anonymous
  May 13, 2005
  The comment has been removed

• Anonymous
  May 13, 2005
  The comment has been removed

• Anonymous
  May 14, 2005
  David,
  Every one of your applications on every OS release? What on earth are you doing to have that poor a compatibility record? There are certainly things that change - applications that grovel internal data structures of the kernel (like some of the utilities you mentioned) absolutely can and will be broken.
  
  But if you use the Windows SDK, you're almost always going to have get upwards compatibility. Not always - there are (and will) be some things that get broken (I can think of about a half a dozen things that WILL be broken in longhorn, for example - I'll be blogging about them at some point).
  
  To give you a taste of the kind of thing that will be broken, one of the security fixes we made for Longhorn is to change winmm.dll to crash if it's handed a bogus pointer. Before Longhorn, winmm.dll would return an MMRESULT_<something or other> error when handed a bogus pointer, for Longhorn, it will crash the application. But no correctly written application should hit this behavior (and if they do, we're already planning an appcompat shim to deal with them).

• Anonymous
  May 16, 2005
  "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."
  
  Or you have to provide a set of "sample code" that works on both the new and the old platform and takes advangae of the new APIs when it can.
  
  
  Ian Ringrose
  www.ringrose.name <- email on web page

• Anonymous
  May 16, 2005
  Ian, actually that's EXACTLY what I was thinking about when I talked about a credible alternative.

• Anonymous
  May 17, 2005
  A point that was overread in my post to the previous article (and that's mostly my fault), is that in Linux obsolete API's work - but when they are used the operation is logged in the system log. This is a way of keeping the applications working, but at the same time pointing out the fact that it should be upgraded to the new API. Basically: Make it work, but the developer/sysadmin gets told about it.

• Anonymous
  May 30, 2005
  I can think of one situation where the Bindary contract can be broken. And it is coming is being supported in the next version of server cpus.
  
  Cirtualization. Which in effect can simulate the archetecture change with PPC X86-64 etc.
  
  So in effect the VM can support the older API, and maintain the LoB support for other apps. and hopfully is one of the reasons that MS Aquired Connectix(sp)
  
  It would be nice to finally get hardware support into the 21st century without haveing to still support 80's based technology.
  (16 bit Bios, required VGA support in graphics cards to allow for POST)
  
  While the move away from DOS based windows (win 9x) Was the first move from that basis. the other moves are to actually get it implemented. (32 bit bios or UEFI(more than likely)) and the evenaully removeal of VGA table look up on the graphics cards (something from way back in my dos programming days)
  
  I believe with VM technology religating APIS from the main platform can allow for a much stronger and responsive platform. IOW the new version of a Platform doesn't have to worry about the binary contract beyond ensureing that the virtualizaion supports it. and teh API can be removed from the main Platform.
  
  Clear as Mud??

• Anonymous
  April 28, 2008
  PingBack from http://famouspeoplesbirthdayblog.info/larry-ostermans-weblog-end-of-life-issues/

• Anonymous
  May 29, 2009
  PingBack from http://paidsurveyshub.info/story.php?title=larry-osterman-s-weblog-end-of-life-issues