> This allows programs should have failed epically to run flawlessly on everything from Windows 95 to Windows 7.

The "upgrade through every version of Windows" videos show Reversi and MS-DOS Executive running on Windows 8. You do have to run 32-bit Windows, though, to get 16-bit compatibility.

You can still run honest-to-goodness PC DOS 1.0 .com files from 1981 designed to run on the original PC out of the box in 32 bit windows 8.

Without recompiling or hunting for old libs?

I know there were a couple of pretty significant glibc upgrades, and IIRC the binary format changed at some point from something earlier to ELF. Hrm. "something earlier" seems to have been the a.out format, based on Eric Youngdale's 1995 Linux Journal article:

The ELF Object File Format: Introduction

http://www.linuxjournal.com/article/1059

Yes, without recompiling. That's the point, a.out is a binary format and if you recompile with current toolchain, you will get ELF.

You will need the original shared libraries and linker, though. They will run.

Thanks.

While the kernel developers never break compat, userland developers are much happier to, which leads to all sorts of issues. Even if your a.out file is statically linked, it might depend on a service that's since been replaced.

This is why when it comes to old (2000 era) Linux games, it's much easier to just run the Windows version in wine than to go through all the hoops to gather old libraries and get the sounds working.

Old Linux games use OSS, which you may get to run. They may also require obsolete Xfree extensions for direct framebuffer access, which the modern hardware will not allow though.

If you are extra unlucky, they may require direct console framebuffer access and unless you have also the old hardware with old drivers, you are going to get it on modern system.

>Apple's utter contempt for backward compatibility is why people who care about their sanity hate developing products for OSX. Which API is Apple going to deprecate and screw me over with today?

You mean like they countless new API versions and frameworks that MS introduces year over year as "THE" way to write Windows programs?

Sure, they might retain binary compatibility, but if you want future-proof your stuff and continue to get updates and changes you have to jump to the new shiny.

AFAIK, Android has never broken it's public API.

If you hacked it and used internal APIs, you were warned - it is all over the documentation and mailing lists, that these are going to change.