[feld]

Linux is not that great at compatibility with old code or old binaries. Windows has always been better at this.

An example of a *nix with good backwards compat is FreeBSD. The FreeBSD cluster has binaries from FreeBSD 2 (1994) that still run. Try that with Linux -- I guarantee you the kernel and glibc broke compatibility. Hell, there are Linux games from early ~2000s that won't run anymore.

[vetinari]

Linux a.out binaries also still run - provided you have the a.out shared libs. But if you have the old binary, why wouldn't you have the old libs?

Also the Linux games from early 2000s do run - you need the libraries they were built against.

[AnthonyMouse]

> Linux is not that great at compatibility with old code or old binaries.

The default on Linux is source code availability. If the ABI changes but the fix is to recompile or change a couple of lines then it's a much smaller issue than it would be on Windows when you can code. And even if you can't, since the default is also redistributability, someone who can may have done it already and the fix will be in the package manager before you even knew it was a problem. Or you can submit a bug which, when the fix is that simple, some random hacker will fix it for you because it looks good on a cv or github history.

This compared with Windows where you have e.g. some driver with sources unknown that needs to be updated to support AMD64, which already supported x86 and was 64-bit clean for some RISC architecture, but now you can't do it at all. Or even more frustratingly, you have the driver source and the fix is very simple but you can't actually use or redistribute it because you're not up for the five grand and six months it takes to get a certificate for code signing.

[userbinator]

On Windows, the usual solution if you can't get source or someone else won't fix it (sometimes even if you can, because figuring out how to set up a build environment to recompile everything is a hassle when you could just change a byte or two... especially if you're not necessarily going to "develop" any further) is to patch the binary. Maybe this is why I find RE tools on Windows have been far better than with Linux or other Unix-like environments.

Or even more frustratingly, you have the driver source and the fix is very simple but you can't actually use or redistribute it because you're not up for the five grand and six months it takes to get a certificate for code signing.

There are easy solutions to getting unsigned drivers working. I do notice that the Windows and Linux community attitudes toward this are different though --- the latter seems to be "no source, can't do anything" while the former is more like "no source, we'll still fix it". We're not all as helpless and controlled by Microsoft as you may think. ;-)

(I'm someone who recently patched a driver for hardware that I had absolutely no familiarity with before. It was literally a 2-byte change after about 3 hours, most of which was spent learning about the device.)

[feld]

> The default on Linux is source code availability.

You live in quite the dream world.

[VLM]

With qemu and other virtualization technology, even software emulation in 2016 will be faster than real hardware was in the 90s. And unlike Windows there are no legal problems with licensing.

[hjek]

True, Linux binaries are not as backwards compatible as Win32 binaries. However, with Wine and Mingw64 being around, Win32 binaries are a totally valid way of distributing software for Linux.