If we look back to programs written for Windows NT 3.1, released in 1993, and assume they run on Windows 11 (because why not?) then that's 30 years of backwards compatibility.
Did I say mindblowing? It's downright mythological what Microsoft achieves and continues to do.
I don't want to estimate how much such hacks they accumulated over time to keep things as compatible as they could.
That would have given 16, 32, and 64 bit compatibility.
Something like xv (last release: 1994, although the binaries were built against Red Hat 5.2 from 1998) still work today, and the source still builds with one very minor patch last time I tried it.
The problem running the binaries is:
% ldd ./usr/X11R6/bin/xv
linux-gate.so.1 (0xf7f82000)
libX11.so.6 => /usr/lib32/libX11.so.6 (0xf7e22000)
libjpeg.so.62 => not found
libpng.so.2 => not found
libz.so.1 => /usr/lib32/libz.so.1 (0xf7e08000)
libm.so.6 => /usr/lib32/libm.so.6 (0xf7d0b000)
libc.so.6 => /usr/lib32/libc.so.6 (0xf7a00000)
libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7cde000)
/lib/ld-linux.so.2 => /usr/lib/ld-linux.so.2 (0xf7f84000)
libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7cd8000)
libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7cd1000)
% ln -s /usr/lib/libjpeg.so.8 libjpeg.so.62
% ln -s /usr/lib/libpng16.so.16 libpng.so.2
tl;dr: much of the "Windows compatibility" is just binaries shipping with all or most dependencies.
Try it yourself: http://www.trilon.com/xv/downloads.html
Available API means the whole stack, everything needed to write applications end to end, regardless of their purppose, not CLI and daemons.
And this is what Windows does too really, with MSVC and dotnet and whatnot redistributables. It's just that these things are typically included in the application if you need it.
It's really not that different aside from "Python vs. Ruby"-type-differences, which are are meaningful differences, but also actually aren't all that important.
Got no counterexamples? Then it's not FUD at all, rather a pure truth.
This seems like it was meant in a positive way, but I really don't think that if compatibility with your system requires "mythological" efforts, that should be seen as a good thing for your system.
It's also worth noting that backwards ABI compatibility only masters when people limit their software by not distributing the source. Early UNIX software can run fine on modern GNU by just compiling it.
API Compatibility Is All You Need ;)
...providing you can find a suitable compiler that isn't obsessed with exploiting undefined behaviour.
Have you ever tried building decades old programs from source? It's not as easy as you claim.
Here's source for grep from v6 unix. I'd be interested to know the smallest set of changes (or flags to gcc) needed to get it to compile under gcc on linux and work.
https://github.com/takahiro-itazuri/unix-v6/blob/0316b457acb...
Still, there is only one actual error in gcc 13.2.1 which is the use of =| instead of the later standardized |=. I'm not sure if that was a common thing back then or if it was specific to their C compiler. Either way, I don't think gcc has a switch to make it work. Switching that around in the source gives linker errors since it seems back then the way to print to or flush a particular file descriptor was to set a libc variable and then call flush or printf. If you had the right libc to use with it that one tiny change might be all you need. But you would likely need to set up a cross compile to be able to use the right libc.
My understanding is that most of the compatability issues on Linux are due to not having the right libraries rather than the kernel not supporting older system calls. It is just a lot of not that fun work to keep things working and no one is that interested (instead, some people just use decade old versions of Linux :/ and the rest use package systems to recompile stuff). NetBSD had better practical binary compatability for a long time, although I think some of it was remove fairly recently since there isn't much commercial NetBSD software (there was one lisp binary from 1992ish IIRC that some people were still using and I think that compat was kept).
But I don't think it was unfair to use that as an example of early Unix software, or to point out that it was harder than "just compiling it". One defense against my argument could be that a version of 'grep' has been maintained through C versions and operating systems, with source code availability playing a part in that (although presumably GNU grep avoided using Unix source code).