Hacker News Reader

Comment by mathw | Hacker News Reader

Because Microsoft have long had a reputation (especially at the time) for maintaining compatibility over a very long period for applications. They did horrendous engineering to make DOS applications still work through Windows 95 and onwards because their customers still needed it. This was considered an important thing for the product.

Windows is still one of the most backwards-compatible systems you're ever likely to encounter. Sure, not everything works anymore, but you can still install a lot of software written for Windows 95 and expect it to still function. That's hugely impressive, given that we're not even running the same kernel anymore.

View on HN

>This was considered an important thing for the product.

Backwards compatibility used to be the norm for most stuff, didn't it? In the 80s/90s. You didn't need to get a new computer every few years. Now if there's a problem, the solution is easy - "Buy a new computer/phone/iPad."

> Backwards compatibility used to be the norm for most stuff, didn't it?

I think this seems true only because of Microsoft. I cannot recall any other major OS spending so much effort on backward compatibility.

> I think this seems true only because of Microsoft. I cannot recall any other major OS spending so much effort on backward compatibility.

The king of backward compatibility is probably IBM. AFAIK, their mainframe operating systems can run unchanged software from before MS-DOS was born.

That's true. You can supposedly run a program assembled or compiled in the 60's on a z14 that you buy today.

Seeing as most of IBM's largest customers are banks and other places that have no interest in rewriting battle tested software, it's probably the reason that their mainframe department is still alive.

SCO OSes are also backwards compatible to hell and back.

This is one place where the Web continues to reign supreme. Did we re-implement an OS on top of our OS? Sure. But it's been a tremendous success for accessibility.

Sorry, I didn't understand any of those sentences.

I mean that the web has been a tremendous success story for long-term backwards compatibility and widespread access. We've lost a few pieces of technology, like Flash, but overall you can take any modern browser and go visit ages old websites and find them fully functioning.

Here's Bob Dole's 1996 campaign site: http://www.dolekemp96.org/main.htm

Browsers are on every platform, and for the most part different platforms require no different code for your web application to work. Mobile vs Desktop, Android vs Windows, you get it all.

Ohh right, thank you for explaining. Hmm but e.g. a lot of new websites dont work on any available browser on my computer. The problem is so many new sites need a new computer to work properly—as if they're only tested by people with new computers—not that new computers have a problem with old sites. Maybe I should, uh, buy a new computer. :-) But I figure there are as many people using computers as old as mine, as using brand new ones, maybe not. But I've realized there are two kinds of backwards compatibility, thanks.

Hah yeah, forwards-compatibility is a separate issue there.

Unfortunately, a lot of software written for Windows 95 comes with 16 bit installers. And there's no 16 bit compatibility in 64 bit Windows.

> And there's no 16 bit compatibility in 64 bit Windows.

Since we're talking about the lengths Microsoft goes towards backwards compatibility: https://msdn.microsoft.com/en-us/library/aa384143(VS.85).asp...

"For older applications that use a 16-bit stub to launch a 32-bit installation engine, 64-bit Windows recognizes specific 16-bit installer programs and substitutes a ported 32-bit version."

(However, this is not always enough: https://davidcmoisan.wordpress.com/2010/02/18/16-bit-install...)

> this is not always enough

Right, I have one 1997 videogame that uses InstallShield 3.0.95.

Yea that was the big break in compatibility. There's also many applications that were written for the specific hardware and many undocumented features (hacks) on 95/98 that modern Windows cannot handle.

> That's hugely impressive, given that we're not even running the same kernel anymore.

Unless you're doing shenanigans with ioctls to devices or direct access to kernel functions, the kernel does not really matter - everything goes through user32 and friends anyway, so as long as MS does a good job keeping this abstraction layer stable OS upgrades don't concern you much.

[...] as long as MS does a good job keeping this abstraction layer stable OS upgrades don't concern you much.

The problem is that you have to keep them stable to a much higher degree than you might think at first. Obviously you have to maintain the functionality as described in the API documentation but that is far from enough. If the implementation has a bug, you can not simply fix it because there might be software either relying on the wrong behavior or having implemented workarounds that you might break with the fix. And no matter how often the API documentation states that this or that is not supported or undefined behavior there will be software doing it anyway or relying on what ever undefined behavior meant in the version they developed against. You return a list of something and say nothing about the ordering in the documentation but as an implementation detail it happens to be in some specific order, if you wait just long enough there will be a program critically depending on the ordering you choose. This is an endless nightmare especially if your APIs have as many different consumers as the Windows APIs.

Out in the wild though everything doesn't go through user32 and friends. Antivirus in particular is notorious for ignoring public APIs.

Reply on news.ycombinator.com