KapedSuperiority brings jealousy
danieltonTry running an old binary on Linux.
Define old binary. The a.out and elf format haven’t changed in a very long time. If you mean something from an old system with unmet dependencies, it will run, but it will crash and warn you that some library isn’t found. It will still run up until that point tho.
Anything 5-10 years old or older. Chances are, it won’t work unless it’s a static binary. Linux has long had a policy of “F backwards compatibility” in the userspace, so you need to dig up the 5-10 year old libraries it needs to run. And for anything 32-bit, you also need to install the 32-bit versions of all your system libraries.
Acting like “old app won’t run” is exclusive to macOS is misleading.
I ran UT2k4 in 2016 or so, it was dynamically linked but brought its libraries, I had to replace some IIRC but afterwards, it ran.
Dynamically linking libraries that ship with the executable is functionally identical to static linking in this case.
Sure, but what is the point of the thread then? Of course a program will need the libraries it was linked against. The kernel has nothing to do with that really. The point was it is possible to run old binaries. Even a recent program will fail to run if its dependencies aren’t provided, that’s not an issue with older ones…
The point is, that under Windows you can take a very old program, sometimes even from the DOS era, and the chances are good, that it will run just fine. UT99 for example runs perfectly under Windows 11 despite being over 20 years older than the OS. That’s mainly because Windows ensures a relatively high degree of backwards compatibility.
Under Linux, running a five year old binary is almost impossible without 500 hacks. That is quite a different experience.