VOGONS

Common searches


Reply 20 of 30, by Jo22

User metadata
Rank l33t++
Rank
l33t++

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.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 21 of 30, by mr.cat

User metadata
Rank Member
Rank
Member

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.

Last edited by mr.cat on 2021-07-20, 14:47. Edited 2 times in total.

Reply 22 of 30, by Caluser2000

User metadata
Rank l33t
Rank
l33t

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..

There's a glitch in the matrix.
A founding member of the 286 appreciation society.
Apparently 32-bit is dead and nobody likes P4s.
Of course, as always, I'm open to correction...😉

Reply 23 of 30, by The Serpent Rider

User metadata
Rank l33t
Rank
l33t

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

Get up, come on get down with the sickness
Open up your hate, and let it flow into me

Reply 24 of 30, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
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. 😉

Reply 25 of 30, by digger

User metadata
Rank Oldbie
Rank
Oldbie

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.)

Reply 26 of 30, by Caluser2000

User metadata
Rank l33t
Rank
l33t
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....😉

Last edited by Caluser2000 on 2021-07-22, 05:27. Edited 1 time in total.

There's a glitch in the matrix.
A founding member of the 286 appreciation society.
Apparently 32-bit is dead and nobody likes P4s.
Of course, as always, I'm open to correction...😉

Reply 27 of 30, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie
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". 😉

Reply 28 of 30, by Caluser2000

User metadata
Rank l33t
Rank
l33t

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.

There's a glitch in the matrix.
A founding member of the 286 appreciation society.
Apparently 32-bit is dead and nobody likes P4s.
Of course, as always, I'm open to correction...😉

Reply 29 of 30, by the3dfxdude

User metadata
Rank Newbie
Rank
Newbie
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.

Reply 30 of 30, by digger

User metadata
Rank Oldbie
Rank
Oldbie
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. 🙂