Larry Osterman's WebLog

Confessions of an Old Fogey
Blog - Title

Turning the blog around - End of Life issues.

Turning the blog around - End of Life issues.

  • Comments 51

I'd like to turn the blog around again and ask you all a question about end-of-life issues.

And no, it's got nothing to do with Terry Schaivo.

Huge amounts of text have been written about Microsoft's commitment to platform stability.

But platform stability comes with an engineering cost.  It gets expensive maintaining old code - typically it's not written to modern coding standards, the longer that it exists, the more heavily patched it becomes, etc.

For some code that's sufficiently old, the amount of engineering that's needed to move the code to a new platform can become prohibitively expensive (think about what would be involved in porting code originally written for MS-DOS to a 128bit platform).

So for every API, the older it gets, the more the temptation exists to find a way of ending its viable lifetime.

On the other hand, you absolutely can't break applications.  And not just the applications that are commercially available - If a customer's line-of-business application fails because you decided to remove an API, you're going to have to put the API back.

So here's my question: Under what circumstances is it ok to remove an API from the operating system?  Must you carry them on forever?

This isn't just a Microsoft question.  It's a platform engineering problem - if you're committed to a stable platform (in other words, on your platform, you're not going to break existing applications on a new version of the platform), then you're going to have to face these issues.

I have some opinions on this (no, really?) but I want to hear from you folks before I spout off on them.

  • Wouldn't it be possible to rewrite the entire OS from scratch, and run all legacy apps through a VM-type layer?
  • Why not ship some sort of virtual machine with Windows, and include previous operating systems to those who need them?

    I'd be very happy if all you could strip out all the dead wood that's made it into XP purely on the strength that someone, somewhere, has an app that needs it.

    Sure, it's nice that I can dust off my old copy of WordPerfect for Windows 6.0a and install it on XP, but I suspect that most users (myself included) would rather their install of XP was smaller, faster, and wasn't held together in places with spit and baling wire.

    When it comes down to it, I think I'd take a fairly hard line, and if an API is superseded then I'll support it in one more OS revision, then ditch it. (I.e. Win 3.1 APIs would have been supported in Win95, but not Win2000.) If you have on old app you need to run, why should everyone else have to suffer as a result? If it only runs in Win 3.x, then run it in Win 3.x -- it's your choice. If I went round complaining that the fan belt from my Ford Model T doesn't work in my brand new Ford Explorer, people would laugh at me...
  • As an addendum to that, one thing that would help enormously with being able to get rid of old APIs is by making use of well documented and open file formats in applications. That way, if my ancient app for doing foo stops working when I upgrade to Win2027 (or whatever Longhorn ends up being called*), then I can buy a new foo app and import the data. Closed proprietary data formats mean that I _must_ be able to run the app that created it or risk losing all my data; if I knew that any similar app would be able to read it, then I'd not be so worried.
  • Like the previous posters said. Scrap the lot of them and provide a VM. It's what MAC did with OS 10 and the improvements because of this were huge.
  • Sounds like they're already thinking in that direction:

    But it might not be something that Larry is allowed to talk about yet...
  • I think that as engineers, we're worried about it because we like elegant solutions. Old API's are not elegant any more. But Microsoft's customers aren't so worried about elegance; they're worried about getting stuff done. If you wrote an in-house Mac app in the 90's, how irritated would you be that it won't run on the new Mac OS X? Would you upgrade to the new Mac OS X or would you continue to use System 9?

    Web apps mitigate this cost, but there's still a bunch of old apps that need compatibility. Just look at the point-of-sale terminal in many stores: DOS. Terrifying? Yes. Functional? Yes.

    Microsoft has just as much obligation to in-house app writers as it does to Tom, Dick, and Jane who want to check their e-mail. Realistically, they have more obligation to corporate consumers because they have more money at once. The normal consumers would need a union to represent them.

    Microsoft will support old API's for a long, long time because that's what supports their upgrade cycle. Upgrades make a lot of money for Microsoft (please correct me if I'm wrong on this Larry).
  • Larry,

    if nothing else is done about that problem, an api absolutely must be carried on forever.

    infact, i think the right question to ask is 'what can be done in order to make it possible to remove an api?'.

    thomas woelfer
  • I'd say to remove the API when the version of the program (OS, library, whatever) that introduced it reaches end-of-life, as long as their is a newer version of the API of course, that way you continue to have support for the ability to do something, just not support for that particular API. I think people get more bent out of shape when you completely remove the ability to do something rather than refactor and improve.

  • I think it's important to note, when answering this question with comparisons to Apple's OS X, that the OS X architecture is completely separate from the Classic Mac OS architecture. If you are writing a completely new platform so that you can toss the last 15 years of cruft, then sure, it's okay to write a new API set and provide a reasonably capable compatibility layer that old apps can use.

    On the other hand, if you're just making incremental upgrades to the same core OS, then you need to be more careful about killing off APIs. If an old API is superseded by a more capable API, has been deprecated by documentation and compiler warnings since the new API was added, and the new API has been around, stable, for at least two, maybe three years, then the old one may be ripe for elimination.
  • The main problem I see with the VM method and the compatibility layer method is that in both cases you are still shipping the old code with the new OS - and thus is still needs to be kept up to security standards and the like, since people will blame MS (or the particular vendor) for any security holes that show up in these situations.

    The only thing I can think of is to allow older OS installs to run inside of VirtualPC - but do not ship the older os's with the new one -, then apply modern security to the vectors in to and out of VirtualPC. This of course raises the question of activation and piracy inside the VM, because you run into situations where people will have issues activating windows server 2003 for the 50th time inside the VM, since they have since upgraded to windows 2253 (Really Good) edition. Or people running server os's under a workstation os.

    So it's almost the VM idea, except without explicitly supplying the older code. Just let them install the old copy of windows they obviously have, since they were using it.

    Looking back that is a pretty random set of comments. Heh.
  • I think personally I would do it much like the .net platform. If there is a way on old APIs, which would probably require an upgrade to the API's. The .net platform is currently marking classes and methods Obsolete. Which means they still work now, however the next version they are not going to be there. I do this in my own apps and have found it a rather pleasant way to make changes to api's web services ect. Oh and in marking them obsolete you also tell them what they should change to.

    So for example NT 3.51 API's could have been marked obsolete in NT 4.0 then removed in Windows 2000. In reality in Longhorn you could be removing API's from 2000.

    Now would this affect upgrading, yes it will. We do still have 2 NT 4.0 servers running, because they need to be there the apps they run will not upgrade to 2000, let alone 2003. However one of my objectives this year is to rebuild all the code on these to .net and put the apps on a 2003 server. Eventually everything in software must be rebuilt upgraded or abandoned. Thats just part of the software lifecycle. I will say Microsoft has done an absolute outstanding job at keeping things so backward compatable for all these years but like you said eventually it becomes so costly to maintain the old code that you have to question is it really worth it.
  • cmonachan, that's the first I've heard about that. It's news to me.

    Shipping a VM solution is interesting (again, this is the first I've heard about it) but it's not really the question I was asking.

    I wasn't asking HOW one could end-of-life an API set, I was asking WHEN. Under what circumstances could this be done.

    What are the criteria for determining when this would be feasable.
  • I don't know if it will ever be cut and dry Larry. Pulling an API is one thing, but you need to ensure something is offered to replace it, and is easy to adopt. And then cut the ties quickly or fear the wrath of the indecision.

    NetDDE is a perfect example. There was a bad escalated privilege vulnerability in Windows 2000 that was carried forward from old DDE code. DDE is pretty much dead... yet many apps still use it. (Unfortunately). DDE evolved into OLE which evolved into COM which evolved into DCOM which is now evolving into Indigo. (I think thats how it goes. Correct me if I am wrong). Pulling DDE sooner would have removed that vulnerability on W2K, or at the very least, minimize its impact. However, there was never a clean upgrade path ensuring there was a mechanism to upgrade without breaking things. And whats worse, just as people were ready to move on, it changed again. So developers didn't touch it.

    I think EOLing an API should come with a painless mechanism or bridge to get buy in from developers. And that has to come over time that is well defined. It can't keep changing. I wish I could give you a good example, but its difficult to think about how deep this problem goes sometimes.

    However, Longhorn is a GREAT time to break compatibility... or at the very least produce a clear and clean path for adoption to the new APIs. The platform is so different, that HOPEFULLY people would be willing to adopt sooner. Bringing back things like Indigo and Avalon to XP were a great start. It allows earlier adoption and a migration path that is easier to swallow in the software management lifecycle.

    Of course, thats a mile high view of things. I am sure each developer will have their own issues, depending on what you pull, and why. If there was an excellent API exposing some key feature my application used and you pulled it, I would probably be irrational and swear up and down about your anti-competitive behavior, unless you offered an alternative to allow me to achieve the same goal, with little impact to my codebase. ;-)

    But that's just me.
  • The problems with getting rid of old APIs are obvious. A VM oriented solution may be workable, but another possibility is splitting the old APIs up into a selective install package, like the Platform SDK or even as part of the OS install. The people that need the old APIs (developers, users) can download this package of APIs and install the ones they need. I realize this is a huge engineering undertaking, especially with testing, but it'd be a way to clean out a lot of APIs from the core OS install. Hopefully, if the APIs really aren't used by many people, the trouble of installing an old API is not a big deal.
  • The VM solution works for applications, but not for plug-ins. Witness the problems that are already being seen on Windows x64 - people complaining that Explorer shell extensions don't work, and that SQL Server 2000 performance counters only work in the 32-bit Performance snap-in, meaning you need the 32-bit MMC, and MS shipping both 32- and 64-bit versions of IE.
Page 1 of 4 (51 items) 1234