Turning the blog around - End of Life issues.

项目
05/11/2005

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.

Comments

Anonymous
May 11, 2005
Wouldn't it be possible to rewrite the entire OS from scratch, and run all legacy apps through a VM-type layer?
Anonymous
May 11, 2005
The comment has been removed
Anonymous
May 11, 2005
The comment has been removed
Anonymous
May 11, 2005
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.
Anonymous
May 11, 2005
Sounds like they're already thinking in that direction:

http://www.enterprise-windows-it.com/story.xhtml?story_id=02200000GA1E

But it might not be something that Larry is allowed to talk about yet...
Anonymous
May 11, 2005
The comment has been removed
Anonymous
May 11, 2005
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?'.

WM_MY0.02$
thomas woelfer
Anonymous
May 11, 2005
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.

-Jeff
Anonymous
May 11, 2005
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.
Anonymous
May 11, 2005
The comment has been removed
Anonymous
May 11, 2005
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.
Anonymous
May 11, 2005
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.
Anonymous
May 11, 2005
The comment has been removed
Anonymous
May 11, 2005
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.
Anonymous
May 11, 2005
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.
Anonymous
May 11, 2005
The comment has been removed
Anonymous
May 11, 2005
The comment has been removed
Anonymous
May 11, 2005
A: When no one uses the API anymore!?

Q: How do you know when the API is not used anymore?

A: During the course of a year (arbitrary), the OS builds a map of unused APIs. At the end of the year it reports them to M$. M$ becomes more informed as to the actual need for each API in the next core release. Rarely used APIs could be released as 'on-demand extensions'.

Q: Can this really be done efficiently???
Anonymous
May 11, 2005
If they won't support it,
then open source it!

(whoo, it rhymes, sort of...)

s/they/you or s/they/Microsoft as appropriate...

The advantage is that you push the cost of maintaining the APIs onto the people who want the APIs. You are now free to remove anything you want, and people can add them back if they really want. The disadvantage is that your proprietary secrets aren't anymore.
Anonymous
May 11, 2005
The comment has been removed
Anonymous
May 11, 2005
As Michael Ruck wrote, use the AppCompat layer to start flagging to users that an API is approaching obsolescence.

It will encourage end users to upgrade to newer, more secure apps that are self repairing as well (via MSIs).
Anonymous
May 11, 2005
I think API should be kept around for quite a long time. That doesn't mean legacy stuff should remain at the core of the OS forever. At a certain point it becomes very acceptable to make legacy APIs available only as optional packages or even downloads.

I'm all for moving the core forward, keeping it lean and fast, and (most importantly) don't let legacy stuff get in the way of doing new things in a better way. Offloading legacy libraries or even entire architectures to an emulator environment isn't out of the question either. It's a cheap means of still providing support while keeping the core clean, thereby drastically reducing dependencies and the strange little effects that creep in because of overall system complexity. (Like Apple did with OS9-type app support under OS X)

Right now, if you guys think Windows is getting too crowded, it might be a good idea to retire DOS and Win3.x-type APIs off to a nice optional emulator. While I think the more drastic idea to retire a large set of Win32 alltogether to motivate vendors towards .NET and related technologies like Avalon and Indigo would have a very rejuvenating effect on the whole application landscape, that would probably not be a good business decision ;-)
Anonymous
May 11, 2005
Two points. First point is an example - The PIF executable file format. How many customers have been infected by it? How useful is it?

Second Point. Apple solved this by adding a OS 9 emulator to OSX, so instead of keeping up with old 9 APIs they just dumped it and started over with a nice fresh 10 set. But without breaking 9 applications.
Anonymous
May 11, 2005
I don't think the OS 9 emulator is that great of a model. I tried running some specialized biological data analysis software on it and there were many problems.

Why exactly do APIs need to be EOLed? If their functionalities are replaced by new APIs, is it impossible to rewrite the old APIs as shims which use the new ones underneath?
Anonymous
May 11, 2005
My opinion would be to move the APIs Microsoft think are due to end their life(I believe Microsoft employees should have good judgement on this)out at a trimed release(possibly before the RTM and after the final beta) and see the impacts. The bug reporting software should return report on any missing function calls. If Microsoft receive such report, they should judge whether it's good to put that back depend on how frequent the report is received. (I know this will add additional cost to the development process, but consider the benefit of removing old functions that's difficult to maintain, I think it's worth to consider.)

For whatever functions that have the whateverEx function they could have a redirector that calls the Ex function with some parameter set to some default value.
(More or less like how Windows use Interrupt redirection to replace work with DOS programs that only knows interrupt but does know APIs)
Anonymous
May 11, 2005
The comment has been removed
Anonymous
May 11, 2005
Larry Osterman posted earlier today about Turning the blog around - End of Life issues&nbsp;and I thought...
Anonymous
May 11, 2005
Provide me a tool I can run against my source or binary that tells me what APIs are deprecated AND what I should do instead. The "what I should do instead" would need to cover Win98 onwards since most developers won't want to disenfranchise that non-trivial portion of the userbase.

You can then rip out the APIs once the deprecation period has expired, which I would expect to be a few years.
Anonymous
May 11, 2005
I'd say that two good times to sunset an API are either when (a) you simply cannot implement it, or (b) you can transparently reimplement it on top of another public API.

NTVDM, for instance, was OK to ditch in x64 Edition because the CPU itself simply doesn't support VM86 in long mode, and writing a full-blown emulator is unreasonable.

LZ32 is used less nowadays and can be reimplemented with simple, basic kernel APIs, so I imagine it could be dropped from the core OS and either moved to appcompat and/or re-released as a redistributable. waveIn and waveOut also come to mind, if they can be reimplemented on top of DirectSound, and perhaps even GDI can have this treatment after Longhorn ships.
Anonymous
May 11, 2005
The comment has been removed
Anonymous
May 11, 2005
It doesn't matter if you make every single piece of software obsolete. Software is almost worthless to end users. What is valuable to end users is data.
So you can, if you like, happily change Windows so that Word 2.0 won't work, as long as there is a piece of software around that will open Word 2.0 files and do something rational with them.
Here, therefore, are some uninteresting cases:
1. In-house-developed software: there is presumably source code around somewhere so pulling the rug out from under feature will not cause your customer disaster, merely expense.
2. "Intimate" software. By this I mean software that doesn't run on top of (or under) Windows but enfolded and entangled with it-- typically something that needs to deal with sound or multimedia or low-level device access. In that case you're relatively safer obsoleting the APIs because this is not application software in the normal sense and probably doesn't have much in the way of unique data associated with it.

For all other cases, the simple rule is that you support the API for ever. Period.

Remember that in the general case the user has no access to the source code (and wouldn't know what to do with it if he did) and the company that made the original program is long since defunct.

On the whole, I must say that MS hasn't been too bad about this so far. We get occasional upgrade requests from people who are using MSDOS versions of our software from the early 1990s: typically they have moved to a new laptop and suddenly find that Windows XP's MSDOS emulation is bagadap. (I'm not sure why, mine works perfectly). Fortunately we're not a dead company... otherwise the problem would have been serious for the user because databases are typically worth more than the computers they run on.

Now, however - if, with .NET, you say that certain features are marked "Obsolete" and will be removed soon... I have no problem with that. But do you undertake, definitely, never to do that again? Or will you decide, in 2008, that some more features need to be obsoleted? In that case no-one with any sense will touch .NET because the risk is too great.

You have to address this problem because software is far longer-lived than anyone ever expected when this industry started. You may happily "end-of-life" your own operating systems, but that is allowable because you normally release a successor OS. You cannot arbitrarily "end-of-life" the application software on which people's businesses depend.
Anonymous
May 11, 2005
I think you should have two strategies for deprecated subsystems and deprecated APIs in the current subsystem.

Deprecated subsystems (e.g. DOS, Win16) could run in a VM like environment. The loss of Win16 is imho a big defect of Win x64 (yes I know the reason is the lack of hw support) and a VM strategy can be a winner here.

For deprecated APIs in current subsystems (Win32 and Win64) we can have a different strategy. Let's have a protected registry tree (or something similar) which contains a list of deprecated functions and a DLL in which they are stored. The OS will simply load the DLL which is a stub for the API or a wrapper on the new API.

For example let's say MessageBoxA gets substituted by a new MessageBoxHTML which uses HTML to format its message. In the registry we'll have something like MessageBoxA : OLDAPI32.DLL. The OS intercepts an unresolved call to a MessageBoxA which is in USER32.DLL (or wherever it is), loads OLDAPI32.DLL on the fly and then call the OLDAPI32.DLL implementation which either does nothing, creates a dialog window with the message or uses the new MessageBoxHTML to show its message.

The wrappers could be quite complex. For example a wrapper which wraps WINMM.DLL wave functions over DirectSound ones could be pretty much complex and not 100% compatible. However often 98% compatible is enough. Eventually the wrappers could be configurable on a process basis (taking the WinMM->DS example we can have the "no sound" option which has 100% compatibility but doesn't output any sound and the "full emulation" which has some corner cases of incompatibility but does its work).

Sorry for the long post.
Anonymous
May 11, 2005
Do it like the Linux kernel does. It becomes obsolete in the next version, and gets removed in the one after. That way everybody gets time to upgrade their application to the new API and warnings get logged in the system log if the application tries to use the obsolete API. This way the program keep working, but the developers are encouraged to upgrade to the new API.

Unfortunately this works well in a zero-cost (free beer) environment where everybody can upgrade without permission from above (re: budget). The proprietary model encourages people to keep using old versions of the software because it's cheap. OS vendors that charge for their OS should release cut-down versions that don't have the extra functionality enabled (and are not as resource hungry), but work with the new API as a free upgrade. This way you could also provide the essentials like patches for free.
Anonymous
May 11, 2005
The comment has been removed
Anonymous
May 11, 2005
Good question, and one that would be moot if the OS license allowed users who had a licence for the current OS to dual boot or run the old OS in a VM for free.

In some senses depreciating API's would be a good thing, at least for 3rd party developers, because it would stimulate the market for new software, rather than allowing old software to continue for ever. Maybe that's tough on customers but MS isn't the only software company in the world that makes money by selling a newer and better (or just prettier) software. Of course if you do it too often or too soon you risk alienating large numbers of customers, but if you announch the EOLing of APIs as you do with OSs several years before you do, and publish a list of affected software, that should be OK.
Anonymous
May 11, 2005
My vote is on major releases only. You publish a list of what is disappearing and what to do about it, like if there is a replacement. I think everyone can understand that. So, Longhorn is a major ... but perhaps even XP-SP2.
Anonymous
May 12, 2005
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.
Anonymous
May 12, 2005
I say if you give enough notice, say 5 years, and offer deprecated support through those years, no one can hold you accountable.

Brett

"OMG!!1 I can't run logo on my new 64-bit dual-core machine running Longhorn?! How will I survive without that fantastic little turtle?!
Anonymous
May 12, 2005
Larry as to the VM & AppCompat layer, I believe Aaron Reynolds and Pierre-Yves Santerre looked into some of this during the early WinXP time frame.
Anonymous
May 12, 2005
The comment has been removed
Anonymous
May 13, 2005
The comment has been removed
Anonymous
May 16, 2005
The comment has been removed
Anonymous
May 17, 2005
The comment has been removed
Anonymous
June 01, 2009
PingBack from http://woodtvstand.info/story.php?id=4556
Anonymous
June 01, 2009
PingBack from http://uniformstores.info/story.php?id=16207
Anonymous
June 07, 2009
PingBack from http://greenteafatburner.info/story.php?id=4477
Anonymous
June 09, 2009
PingBack from http://quickdietsite.info/story.php?id=14192
Anonymous
June 16, 2009
PingBack from http://lowcostcarinsurances.info/story.php?id=2598
Anonymous
June 18, 2009
PingBack from http://onlyoutdoorrugs.info/story.php?id=89
Anonymous
June 19, 2009
PingBack from http://mydebtconsolidator.info/story.php?id=8894
Anonymous
June 19, 2009
PingBack from http://debtsolutionsnow.info/story.php?id=8102

通过

Turning the blog around - End of Life issues.

Comments

其他资源