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.
Then, the last time I tried to run a binary from the 90s, it required libc5, from the days before distros switched to glibc.
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.
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.
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.
I've been down that road, there's nothing good to say about it.
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.
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.