End of Life Issues

re: End of Life Issues

Dan — Fri, 13 May 2005 01:42:59 GMT

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?

re: End of Life Issues

Dan — Fri, 13 May 2005 01:52:14 GMT

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.

re: End of Life Issues

vince — Fri, 13 May 2005 04:32:59 GMT

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.

re: End of Life Issues

Drew — Fri, 13 May 2005 04:48:22 GMT

I don't actually have my own x64 box (yet). There's a big lab full of machines if I need to borrow one, though.
And I didn't actually even build for x64. I just checked out the header and the SDK entries for the APIs. Until I looked in mmsystem.h I had forgotten that some headers still have this in them:

#ifdef _MAC
#include <macwin32.h>
#endif //_MAC

That amuses me.

re: End of Life Issues

LarryOsterman — Fri, 13 May 2005 06:23:20 GMT

Vince, that doesn't end-of-life the API.

You still have to support the v1 of the API.

Just because you shipped v2 doesn't somehow magically make v1 go away. The question here is when can you nuke the v1 library.

Linux doesn't solve this either, the platform stability guarantees that Linux provides aren't binary guarantees, they're source code guarantees (and even then, the're very weak).

re: End of Life Issues

nutzo — Fri, 13 May 2005 08:16:55 GMT

As Window Snyder has told just perfectly:
"Every time we rip a feature out because it is old and we think no one is using it, our customers scream that we are using it, and over the life time of Windows, that adds up to a significant code base."

The main problem is that Windows really is
a binary/executable OS. You cannot simply talk
about compile-time compatibility (that can be
solved well with 'obsolete' warnings or other
decent compiler tricks), but you need to be
run-time compatible.
Sadly "current" applications are "DLL-hellish".
That is a fact. As long as you have these
kind of apps around you must create a runtime
environment that supports DLL-hell (no matter
how clean/well is your "new" OS is).
It wouldn't be a problem if the Windows would
have grown up in an Open-Source community,
since that way you - most probably - would
have access all "crucial" sources (talking
about apps not the OS itself).
If you have access to the source, you can still
revert the run-time compatibility to a
compile-time one.
Sadly this is not the case here. So you have
quite a few options:
- hire the Wizard of Oz (I guess at Microsoft
he is Raymond Chen) who does the run-time
patching of the affected apps and creates
the DLLhellish environment until the end
of time, so that you can have satisfied
customers
- create a new application that does the same
as the "old" non-working one, forcing
customers buying a new tool instead of the
old (still good) one that worked just fine
with the old OS (well at least would drive
me nuts if it turns out that my $500 tool
stops working after the next OS release,
but that would kill me if there would be
no update to my tool (vendor went bancrupt)
-> surely it is definetely not the
responsitibility of Microsoft, but it is
still a valid/real-life scenario
- do not support run-time compatibility ->
making customers mad, that's for sure

So my opinion is: It is impossible to have
a solution that satisfies everyone. You must
value the pros and cons;
- do I gain more from breaking the app.
compatibility and most probably ending up with
lots of annoyed customers
- or is it simply just not the time when these
changes are worth to be done (please do not
tell me that the time is never right to do
changes, there IS when the extra features
(let it be stability or new stuff) simply
satisfies the customer as well and making them
forget the "pain" that loosing some apps would
cause).

But please do not forget the other (internal
design) aspects of supporting backward
compatibility. As your code-base grows, there
will always be lot of security risks floating
around coming from the "outdated" design
coming from the old-code (so it is not just
the customers' happyness that must be weighed,
but the cost of internal maintenance as well).

re: End of Life Issues

John Elliott — Fri, 13 May 2005 11:38:25 GMT

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.

re: End of Life Issues

AndyM — Fri, 13 May 2005 13:17:21 GMT

"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 :-)

Windows appcompat contract?

James Risto — Fri, 13 May 2005 15:15:49 GMT

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?

re: End of Life Issues

LarryOsterman — Fri, 13 May 2005 15:39:31 GMT

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.

re: End of Life Issues

Andrew — Fri, 13 May 2005 18:32:41 GMT

Fascinating stuff, as always. More than ever it just underscores the need to be as sure as you possibly can that you've designed your API correctly before releasing it in a product. Once an API is in the wild it's out there essentially for good.

I work on test & measurement equipment and we export a string based API over a physical interface known as GPIB. A roll of our hardware platform means nothing to our customers, they expect the same physical interface and API to be present on our new box, the same as the old box. This means that for an existing API we are *never* in the situation where we can guarantee that there are no apps that call our API.

I'd be very interested to hear your thoughts on how the problem of designing and reviewing APIs should be tackled.

re: End of Life Issues

Jo-Pete Nelson — Fri, 13 May 2005 20:53:01 GMT

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.

re: End of Life Issues

vince — Fri, 13 May 2005 21:59:43 GMT

LarryOsterman Said:

> You still have to support the v1 of the API.

Why? Just freeze it as is, maybe with some extremely minimal support to fix security issues. If people want new features, they can port to the new version of the library.

> Just because you shipped v2 doesn't somehow
> magically make v1 go away. The question here is
> when can you nuke the v1 library.

After a period of time, say 5 years after announcing it is no longer supported, just stop installing it by default. People who still need it can enable it by hand.

> Linux doesn't solve this either, the platform
> stability guarantees that Linux provides aren't
> binary guarantees, they're source code guarantees
> (and even then, the're very weak).

Again you are being abit confusing here.

"Linux" refers only to the kernel.

Linux the kernel is _very_ strict about supporting syscall-level compatibility, the whole way back to version 1.0 and before. I have run extremely old binaries ( amusingly, a CD-rom playing app like your series) that were in the a.out executable format, linked against libc4, and against extremeely old Motif library... and yet still managed to run fine.

The sycall level binary compatibility is very important to Linux developers.

The kernel-internal API is not though. Which is why you can't use binary-only device drivers without a lot of hassle. That's a different issue though.

What the Linux DISTRIBUTIONS do is an entirely different story and varies from project to project and vendor to vendor. Though typically they work in the way I described. Older programs might be linked against the 1.0 version of the gtk+ library. THat library has been obsoleted and is not installed by default on newer distros, but you can get it and install it by hand if needed. Most users don't, and most programs do keep up to date with current library releases.

Commercial programs for Linux do often link against extremely old versions of libraries, which is they primary reason the distros still try to maintain the older libraries.

And before you claim Microsoft sainthood based on how well you keep compatibility, I find I can run old DOS games using the "dosbox" emulator on Linux and MacOS a lot smoother than on my girlfriend's machine running modern Windows.

re: End of Life Issues

LarryOsterman — Fri, 13 May 2005 22:18:23 GMT

Vince,
The discussion here is "when can you REMOVE the API". You're asking "when can we IGNORE the API".

As long as the code to implement the API exists, it's going to have to be supported. And apps are going to call it. And they're going to expect that the APIs will continue to work, regardless of what happens on your platform.

Unless you're proposing reinventing DLL hell? There are two subtly different but similar versions of a DLL on the system - one offers one set of functionality, the other offers a somewhat different set of functionality, and apps have to choose which one they're going to use?

re: End of Life Issues

David Candy — Sat, 14 May 2005 09:53:56 GMT

1. Norton has broke on every new win release. Unfortunately I always have had the beta of the next Win when I've aquired NU. They don't feel any need to support their products. It's hard to whinge as I last paid cash for Ver 7 (and I still have ver 7 (with libraries) and 6 (standalone) files. But by sending a tip in to the SMH you get a free copy. I no longer bother as it won't work for very long.

2. MS has broken EVERY SINGLE ONE of my applications. This "contract" excludes me.

3. Like with the Win 95 aware header for Win 16 programs, break the API on new programs, wait a decade then kill the API.

re: End of Life Issues

David Candy — Sat, 14 May 2005 09:54:34 GMT

re: End of Life Issues

LarryOsterman — Sun, 15 May 2005 01:11:25 GMT

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).

re: End of Life Issues

Ian Ringrose — Mon, 16 May 2005 17:05:42 GMT

"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

re: End of Life Issues

LarryOsterman — Mon, 16 May 2005 19:08:05 GMT

Ian, actually that's EXACTLY what I was thinking about when I talked about a credible alternative.

re: End of Life Issues

Norman Rasmussen — Tue, 17 May 2005 20:16:41 GMT

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.

re: End of Life Issues

Douglas Husemann — Mon, 30 May 2005 23:14:30 GMT

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??

Famous Peoples Birthdays » Larry Osterman’s WebLog : End of Life Issues

Mon, 28 Apr 2008 16:51:00 GMT

PingBack from http://famouspeoplesbirthdayblog.info/larry-ostermans-weblog-end-of-life-issues/

Larry Osterman s WebLog End of Life Issues | Paid Surveys

Larry Osterman s WebLog End of Life Issues | Paid Surveys — Sat, 30 May 2009 13:00:21 GMT

PingBack from http://paidsurveyshub.info/story.php?title=larry-osterman-s-weblog-end-of-life-issues