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?

Caluser2000 wrote on 2021-07-28, 02:15:

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?

i feel bad i didn't see this for 3 years 🤣 but it was a Dell Dimension 4100 - P3 1ghz, Intel 815E, ATI 9550, SBLive. Fedora won't boot from the IDE2SD I have, but I could make a Fedora boot floppy that would read from the SD.

The XFree86 "radeon" driver has been enhanced by Red Hat to include experimental 2D-only support for some of ATI's newer hardware, including the following models:
- Radeon 7000 IGP (A4+) 4237
- Radeon 9000 IGP (A5) 5834
- Radeon Mobility 9000 IGP (U3) 5835
- Radeon 9200 (AGP) 5964
- Radeon 9600 AP (AGP)
- Radeon 9600 Pro AR (AGP)
- Radeon Mobility M10 NP (AGP)
- FireGL (R350) AK (AGP)
- Radeon 9800 NH (AGP)
- FireGL (R350) NK (AGP)
NOTE: The new Radeon driver support has been included for people to test and to help identify possible instabilities requiring additional work in the future. Note also that there are even newer models of ATI hardware that are not supported at this time.

https://archives.fedoraproject.org/pub/archiv … EASE-NOTES.html
That does not sound like using Fedore Core1 has dri-support built in ?

The fedora release notes probably is referring to XAA support in the radeon driver. I'm not sure if that is a result of the tungsten graphics team or not, but at least it sounds like something that came out of XFree86. The radeon driver probably was still fairly new for its time.

Though I think Queen K Juul was saying he is using fglrx, which means he is using that instead, which ATI wrote specifically to support the new radeon line of cards. That would make sense why he got things working on old linux. It would be interesting that there were no problems at all. I tried fglrx on a brand new at that time Radeon 9200, and it didn't work very well. Then I switch to radeon+dri and stuck with the open source stack ever since. Perhaps the 9200 was just too new for the time, and the 7000 was stable by then.

I guess there aren't enough old (closed-source) Linux games to warrant its own section 😀

Looks like the Mesa ticket that was raised was closed as fixed in May 2022 by simply removing the code causing the crash as part of st_glsl_to_tgsi removal and landed in Mesa 22.2. Perhaps it might work now or reveal other issues (in trying to get it to run on modern Linux using i386 libraries).

I had Loki ports of a bunch of games and even when new they would often break, or fail to install on distros that others were successful with. It would take real system modifications to get libraries that would run the games. When Loki went out of business I think it was electronics boutique that put them on clearance and I bought a few I didn't have, I couldn't get them to work even then. I have a few of these still. It would probably take a real masochist to try to make these work today.

The Loki Myth 2: Soulblighter CD-ROM can be used to play the game on modern Windows, macOS, Power PC Macs and Linux thanks to the continuing efforts of Project Magma: https://projectmagma.net/downloads/myth2_updates/

If you want a guide for playing this particular game these days, see this post on the Tain.