When running Xorg/X11 they do still run, that protocol from the old days has not changed much, its the libs that the programs use are the moving target, but if you have a nice static compiled X11 App, it will still display!

TWM keeps working fine on the latest version of Linux, and TWM predates Linux for many years!.

> I wish desktop Linux had even a fraction of that level of backwards compatibility.

Try on Mac!

> I wish desktop Linux had even a fraction of that level of backwards compatibility.

The compatibility is mostly at the level of the source code. You can compile linux programs from 20 years ago and run them. The only friction is that the compiler may print a few warnings. Binary compatibility is a moot point when you can recompile stuff so easily.

I tried to run Soldier of Fortune for Linux (of Loki fame) and it isnt possible due to 32/62bit compatibility issues. I cant imagine running 16bit software...

Linux doesn't have 16-bit software.

Does that have any interesting 16-bit software you might want to run on Linux?

Well, it's at least interesting enough to exist, beyond that I couldn't say. Bit subjective of a goal post don't you think?

Only on a 32 bit installation, you can't run 16-bit applications on a 64-bit machine.

Devil’s Advocate counterpoint - being able to still run Win1.0 is evidence of the baggage that Windows is carrying around, and maybe it would do them some good to eventually cull out some old cruft. The transitions will naturally be painful, but how much further and faster could they go if maybe they stopped supporting code from 35 years ago?

IBM Mainframes laugh at Windows backward compatibility. 50-60+ years isn't unheard of. I actually want to at some point climb that cliff but my next write up is exploring Windows 3.11's networking features, and then Novell NetWare; the Windows one should go up tomorrow on SN, and NetWare next week.

I look forward to the NetWare one!

Have you read an article?

1) It specifically needs the 32-bit version of Windows.

2) It won't run on 32-bit Windows 10 without an additional installation (NTVDM).

I don't see any "baggage" which limits anything, for any "normal" user.

Yep, when trying to learn Windows programming in 2020, you can literally see the geological layers of APIs accumulated over time... It does not make things easy. Not to mention that development on Windows team in MS must be a nightmare...

I wonder if it would be a good idea for them to remove a lot of the old APIs and instead provide a seamless virtualization mechanism for running the old binaries.

Desktop Linux has all of that compatibility. Nothing fundamental has changed: You need the libraries, and if you have them, it works, just like in Windows.

Are you aware that the original binary format of Linux was not ELF?

Then, the last time I tried to run a binary from the 90s, it required libc5, from the days before distros switched to glibc.

> Are you aware that the original binary format of Linux was not ELF?

Yes, and having an a.out interpreter is just another dependency.

> Then, the last time I tried to run a binary from the 90s, it required libc5, from the days before distros switched to glibc.

It's a library. libc is versioned like everything else.

Nobody is distributing that library anymore. Whereas an equivalently aged binary on Windows will load today without extra dependencies.

I would think that the kernel would have dropped binfmt_aout by now, but I just looked and it's still there. Wonder if any distros build it.

> Nobody is distributing that library anymore.

There exist plenty of archives of old Linux distributions. "Nobody" turns out to be quite a lot of people/servers.

> Whereas an equivalently aged binary on Windows will load today without extra dependencies.

I wouldn't go so far. The 64-bit port of Windows dropped support for all 16-bit applications, whereas they still run flawlessly through Wine.

No, not really. You can get chroots to run on a command kernel but ABI changes happen without soversion bumps which stupidly complicate matters. Godhelp you if your application tries to use weird ALSA or even worse, OSS features.

I've been down that road, there's nothing good to say about it.

I have plenty of experience which says otherwise, both for Windows breaking compatibility and Linux keeping it.

The actual form of backwards compatibility in Linux is "gcc still builds the C and bash still runs the shell script".

Which is nice in that most every distro carries around a gazillion packages of obscure old code that still builds, but it also means that binaries are heavily disrespected, and the development environment is and forever remains centered around the GNU toolchain.

> Godhelp you if your application tries to use weird ALSA or even worse, OSS features.

What's a weird ALSA or OSS feature? What do you expect in its place?

OSS as an API was really dead simple. open, ioctl, read or write... That interface is still working fine on FreeBSD.

There is an OSS to ALSA compatibility driver.

I'm sure whatever you're expecting (pulseaudio? yech.) can fake being an ALSA device enough to fool anyone.

You would think mapping memory, files, pipes and general IO would have stabilized by now, at least in their basic forms.

They did in 32-bit Windows (NT3.1 is pretty much the same on a core level from Win 10). The problem here was that the 8088 suffered from segmentation which put "interesting" constraints on programs, and then Intel's 80286 was alded to the point that it was only successful in the sense of "faster 8088" and not bringing 32-bit computing as was promised.

I was talking about linux in the era of virtual memory.

The 286 is a 16-bit CPU, it never promised 32-bit computing. That was its successor, the 386.