This reminds me of Kylix, the Borland Delphi version for Linux.
It was a neat piece of software, but the limited ABI compatibility of Linux killed it before it became successful.

IMHO, that's a general problem of *nix systems.
Everything focuses on the source code and portability.
Binary compatibility is an afterthought.

Even the executable format (COFF, ELF, PE etc) will vary over time and with different distributions.

What's also easiily forgotten is the dependency on certain packages.
But not only is the package at such important, but also its version!

If you have a Win32 program from the 90s, you can run it on the current version of Windows.
Some simple program like notepad.exe from Win95 will run flawlessly.

On Linux, that's not the case.

A program written aeons ago will also need the old packages from that time.

Or let's put it that way :
An old game/program was written to use SDL1, but your current *nix does ship with "SDL5" only.
So in order to get your old game/program working on the new systems you have these choices:

a) Modify the game/program for "SDL5"
b) Modify and compile SDL1 from the sources, so it will run on your system
c) Run your game/program an older, period-correct *nix from the era your program/game was made (you use them in an emulator)
d) Give up and use a substitute for your game/program

c) Is like the most feasible, because something like SDL has dependencies on its own.
In the end you'd have to essentially rebuild a whole *nix system, anyway, because the numbers are in the hundreds.

This "dependency hell" is the unix counterpart to the classic "DLL hell" on Windows:
Many different versions of the same library are required to be run on the OS.

Edit: Typos fixed, text cleaned up.

Jo good points, source compatibility is where it's at.
I think I read some years ago that the binary compatibility was made a fast moving target in Linux on purpose, so that Nvidia would have an incentive to open source their drivers.
Idk if that's true but that would explain some of it...
On Linux it's often enough if you can provide all the library files that are needed by the executable (listed by ldd), but that only works to a certain point.

I wonder how the *BSDs deal with the different Linux versions? They have some kind of Linux compatibility layer that's supposed to take care of it, but haven't used it myself.
Actually they can run binaries from other Unixes beyond Linux too (like SunOS, but that's pretty close to BSD anyway).

EDIT: digger's post below answers both of these questions. In the case of BSDs I guess they're just using the host system's drivers, so the binaries will work as long as the needed libraries are provided.

I should imagine if the game soiurce code was available it shouldn't be too hard t0 bring the game up to be used on later LINUX/8nix. I mean the source files in KDE 1 were compiled to run on newer kit about 6 years or so ago to calibrate an anniversary of its creation..

I wonder if it's possible to launch original Quake 3 Arena linux distro on something like Mint.

Caluser2000 wrote on 2021-07-19, 23:35:

I should imagine if the game soiurce code was available it shouldn't be too hard t0 bring the game up to be used on later LINUX/8nix. I mean the source files in KDE 1 were compiled to run on newer kit about 6 years or so ago to calibrate an anniversary of its creation..

Not true for un-maintained source codes. There are minefields of deprecated libs, compilers toolchain and languages standards. It's called "job security" for software developers. 😉

I've seen multiple people blaming unstable ABIs in Linux for this, but at least in the case of the Linux kernel, the ABI is actually sacred, at least when it comes to the software running on top of it.

It's actually codified in the first two rules of Linux kernel development and maintenance, as hammered into developers' minds by Linus Torvalds:

"The First Rule of Linux kernel development: You do not break userspace."

"The Second Rule of Linux kernel development: YOU DO NOT. BREAK. USERSPACE."

The driver interface is of course a completely different matter. (There is no driver ABI at all, and that's deliberate.) But the lack of a driver ABI doesn't affect applications and games.

The main cause of ancient binaries often failing to run on modern Linux distros is the dependency of said binaries on very old versions of certain dynamic libraries.

I agree with others here that a container-based solution such as Flatpak or AppImage would be the best solution for this. (There's also Snap, but that's only really being pushed by Ubuntu.)

digger wrote on 2021-07-20, 00:07:

I've seen multiple people blaming unstable ABIs in Linux for this, but at least in the case of the Linux kernel, the ABI is actu […]
Show full quote

I've seen multiple people blaming unstable ABIs in Linux for this, but at least in the case of the Linux kernel, the ABI is actually sacred, at least when it comes to the software running on top of it.

It's actually codified in the first two rules of Linux kernel development and maintenance, as hammered into developers' minds by Linus Torvalds:

"The First Rule of Linux kernel development: You do not break userspace."

"The Second Rule of Linux kernel development: YOU DO NOT. BREAK. USERSPACE."

The driver interface is of course a completely different matter. (There is no driver ABI at all, and that's deliberate.) But the lack of a driver ABI doesn't affect applications and games.

The main cause of ancient binaries often failing to run on modern Linux distros is the dependency of said binaries on very old versions of certain dynamic libraries.

I agree with others here that a container-based solution such as Flatpak or AppImage would be the best solution for this. (There's also Snap, but that's only really being pushed by Ubuntu.)

Thank you for that clear concise explanation.

I'm curious as to why this thread was started in the first place....😉

digger wrote on 2021-07-20, 00:07:

It's actually codified in the first two rules of Linux kernel development and maintenance, as hammered into developers' minds by Linus Torvalds:

"The First Rule of Linux kernel development: You do not break userspace."

"The Second Rule of Linux kernel development: YOU DO NOT. BREAK. USERSPACE."

The Linux kernel perception of user-space is *NOT* what the apps perceived as user-space. There can be layers of "making developers' life easy" libs between the low-level libs that interface with the Linux kernel "user-space" and the high-level libs that the apps actually use. The ABIs among the layers of libs had been broken time after time throughout the history of Linux evolution. So one came up a *brilliant idea* called lib.so numbering. So whenever the ABI changed, the numbering incremented. It applied for the entire libs even though the apps only called "just_tell_me_your_damn_version()". So another dude came up with counter-measure to the brilliant idea of lib.so numbering, "just symlink all of them" and now everyone's back to square one.

That is the story of Linux with the double-edged sword of Stallman's vision called "FOSS". I came to appreciate how true the wisdom was told repeatedly as in "There is no such thing called Free Lunch in this world". 😉

Can't say I've had many kernal panics or lib dependency issues. When I have it's been doing silly stuff like try to install applications from one distro to the other a few years apart. Xandros 2/3 pulls in the Debian Sarge archives and programs run just fine. Kernel panics usually indicate there is a hardware issue from what I've seen.

Caluser2000 wrote on 2021-07-20, 21:30:

Can't say I've had many kernal panics or lib dependency issues. When I have it's been doing silly stuff like try to install applications from one distro to the other a few years apart. Xandros 2/3 pulls in the Debian Sarge archives and programs run just fine. Kernel panics usually indicate there is a hardware issue from what I've seen.

Same here really. In the case I could not trace to a hardware problem, and there really was a bug, I fixed the bug 😀

I've never really had a problem with libraries. I think it really comes down to having a good distro that pays attention to people's needs and has good tools to manage libraries. I have not had a serious issue with my old Loki games.

kjliew wrote on 2021-07-20, 21:17:

digger wrote on 2021-07-20, 00:07:

It's actually codified in the first two rules of Linux kernel development and maintenance, as hammered into developers' minds by Linus Torvalds:

"The First Rule of Linux kernel development: You do not break userspace."

"The Second Rule of Linux kernel development: YOU DO NOT. BREAK. USERSPACE."

The Linux kernel perception of user-space is *NOT* what the apps perceived as user-space. There can be layers of "making developers' life easy" libs between the low-level libs that interface with the Linux kernel "user-space" and the high-level libs that the apps actually use. The ABIs among the layers of libs had been broken time after time throughout the history of Linux evolution. So one came up a *brilliant idea* called lib.so numbering. So whenever the ABI changed, the numbering incremented. It applied for the entire libs even though the apps only called "just_tell_me_your_damn_version()". So another dude came up with counter-measure to the brilliant idea of lib.so numbering, "just symlink all of them" and now everyone's back to square one.

Yeah, indeed, it's basically the Linux variant of "DLL Hell", I get that. But again, all those intermediate dynamic layers of libraries and middleware between the boundary of Linux user space and the game binary can be isolated and packaged in standalone Flatpaks and such. And in a redistributable manner too. So there's still no reason to resort to emulation or virtualization. Or having to clog op your system with outdated and potentially conflicting libraries, or hacky wrappers or shims. That was basically my point. 🙂

In case anyone is wondering, I was never able to get Heavy Gear II running on modern hardware, but I was able to get it running on vintage hardware. Fedora Core 1 turned out to be pretty ideal, with no dependency hell thanks to everything the game expected to be there already being in place. AMD still hosts the vintage fglrx drivers on their site, I needed to hunt down the version for XFree86 4.3 (I think I found that by looking up the ATi 7000 series drivers). Everything worked, including joystick. I may have used alsa-oss for audio, I can't remember, but that's the only tweak I remember having to worry about.

Queen K Juul wrote on 2021-07-28, 01:42:

In case anyone is wondering, I was never able to get Heavy Gear II running on modern hardware, but I was able to get it running on vintage hardware. Fedora Core 1 turned out to be pretty ideal, with no dependency hell thanks to everything the game expected to be there already being in place. AMD still hosts the vintage fglrx drivers on their site, I needed to hunt down the version for XFree86 4.3 (I think I found that by looking up the ATi 7000 series drivers). Everything worked, including joystick. I may have used alsa-oss for audio, I can't remember, but that's the only tweak I remember having to worry about.

Out of interest sake what was the older hardware you used?

FedoraCore1 is from 2003, perhaps there is a Debian Woody is equal to fedora in terms of compatibility?