Quoting: CyrilBut seriously, at the beginning, what is the reason to use old OS (except fun or nostalgia)?

There are many reasons why applications are created for outdated versions of Windows/Mac/Amiga. We are a weird exception that doesn't has a big retro community. I think it's terrible sitaution.

The idea behind GOG was the need to preserve games for older versions of DOS/Windows.

I saw some posts from users complaining that games from Loki, id software, etc., aren't available on Steam or GOG. I don't see too many posts about classic indie games for Linux.

I want to see something like GOG offering many games available for Linux from 1994 to 2012.

Quoting: CyrilI hope you don't connect your old machines/systems on Internet...

No, I prefer single-player games.

Quoting: CyrilI think if you have to use an old OS, there is a problem somewhere.

The main issue is that we don't even have a modern Linux distribution for old computers. The distribution with kernel 2.4/2.6/4.0 for x86 with all the security patches, the default OSS support, and the set of old libraries. It should contain something simple like IceWM and the modern web browser. The customized Linux distribution to only play old commercial/freeware games.



I read comments of other users above.
I don't understand the idea that we should never use the older version of the Linux distribution. It's hard to point out users of the operating systems or game consoles that don't play games in this way.

It's horrible information to companies that they should support games for more than a few years or Linux users Proton.

What's the point of creating games for Linux if the expectations of users are too high?

I'm skeptical about Linux as the perfect platform where users never have issues with new or older games. It's unrealistic, and Linux x86-64 looks like a good platform for games released 1-4 years ago if they aren't regularly updated.

I accept many of these issues with some games for Linux, and I found a simple way to deal with these limitations of the operating system.

How many times do you want to install a game quickly, and you get stuck with an issue?

We can blame companies and versions of libraries or lower our expectations about Linux to a minimum. People work in these companies, but not machines. When we start demanding too much from them, they can stop developing games for Linux.

I prefer to have more poorly supported games than have the opposite situation. The better support frequently comes with higher sales of games for Linux.

We could see it with many games for Windows where quality isn't always a priority.

Quoting: lucinosThe way you put it is very misleading. Linux kernel never broke ABI. The problem is that you do not rely only on the kernel but also on other libraries and what is part of a linux system? Nobody knows. The usual suspects breaking old software are the desktop environments. But also relying on a library that may be abandoned on the future or not giving a shit about the software that rely on it is what causes problems. (saying doesn't handle old ABIs is misleading because that was never meant to be an ABI, it was just some random dependency)

I never said it was the issue with the kernel. Same with Windows - kernel is only a small subset of what games are using from the common ABIs. And Wine supports practically all common ones, since as you can see, most games are working there fine.

Linux has a pretty comparable set of common ABIs, but how stable they are is really questionable. Stuff like openssl changing and so on is an example of that (and old Linux games borking becasue new openssl has a different ABI). Linux usually expresses breaking changes in the ABI in increasing the soname index or more radically, in renaming the library even.

So how does Wine do it? It's constantly playing the cat and mouse chasing game for new Windows ABIs and at the same time continues supporting old ones way past Windows itself supports them even, by translating them into whatever modern Linux provides.

Something comparable could be done on Linux for old ones (obviously no need to chase new ones) by translating obsolete and old ABIs into modern ones. But it's a substantial effort.

SDL kind of did that by translating SDL 1.2 into SDL 2 and so on. But that's just a single example.

For Linux to be comparable to Wine in that, such kind of idea has to be applied to a lot of stuff.

Last edited by Shmerl on 30 June 2023 at 7:04 am UTC

People don't explain every little thought and where it came from. There are different contexts for using the term ABI... if you're talking about the kernel being able to execute binary formats, no they don't break that. Glibc doesn't break their ABI very often either (and even since they have, the kernel still has backwards compatible support for old ones). Your kernel and system headers define APIs that direct your toolchains to produce critical low level binary interfaces.

We tend to interchange API (Application Programming Interface) and ABI (Application Binary Interface). Shmerl is actually using the correct terminology. In a nutshell, the API is what your programmers use. Defined in the headers you include, for example. This is at code authoring and build time (preprocessing, compiling, linking binaries, linking against shared libraries). What we are really translating with Wine is the Windows ABI's. Linux and Windows have different application binary interfaces. Different binary formats, at that level we're talking about.

You compile those programs and/or shared libraries they link against. At run time, now you're using the "ABI's". Your application has to interact with libraries and the kernel and system back ends. How are the functions stored and retrieved? What integer types, constants, registers, stack sizes etc.

Many libraries and system components try not to break their API's or ABI's. You see some libraries whose sonames never change (or never change major versions). Glibc is like that except it uses symbols to prevent loading older ABIs when compiled against newer APIs. The two terms are related, but they mean different things.

Mesa is like that too, for another example, they never break their ABI. It's usually forwards and backwards compatible... even if you can't recompile the ruddy thing against current mesa (code needs updating) the binaries will still probably run. Most libraries are not like that though.

Quite often new library versions break BOTH. Project foo gets upgraded to version 3 and now it has different .sonames for its libraries. It breaks everything linked against them. So now you go to recompile the program in question, and it barfs on included headers, and things declared wrongly, integer types clashing etc. Now it is said that project foo is neither binary nor source compatible. It may be that functions will need to be rewritten, headers included differently etc.

If you can just go rebuild your application and it compiles, links and runs, then the ABI hasn't changed, only how you interface at the source level (the API).

Projects bump .sonames for both reasons.

Quoting: GroganQuite often new library versions break BOTH. Project foo gets upgraded to version 3 and now it has different .sonames for its libraries. It breaks everything linked against them. So now you go to recompile the program in question, and it barfs on included headers, and things declared wrongly, integer types clashing etc

Exactly. And we can't recompile games provided as blobs (and then never updated anymore either). That's why being able to use old ABIs is so critical for gaming and why Wine enables running even old games well. On Linux this preservation of old ABIs was never a general goal, especially for the gaming use case.

Someone can address it of course, but very few did so far (like SDL example above), so it's far from enough for native games to be on the same level of long term playability as Windows games in Wine in that sense.

A major good exception from that are games with open source engines and the likes of ScummVM and etc. They can be recompiled and don't have this issue.

Last edited by Shmerl on 30 June 2023 at 6:58 pm UTC

Quoting: denyasisCause that's not true. It take more than a minute to find an older version of Linux. Then to install it. Then to configure it. Then to troubleshoot it because it's so old it has trouble with modern hardware.

You do all these things only once. I don't recommend using the older Linux distribution for anything other than games. You only have to install Nvidia drivers to play games. You don't have to troubleshoot it if you have an older computer for this purpose.

Quoting: denyasisThen you can dual boot. That part takes a minute. And most of us don't have the luxury of have 4 gaming systems from different eras to play with.

Well, it was cheap because the price of any of these two computers (Pentium 4 and Athlon XP) wasn't higher than 80 zł (20$). Of course, computers with Pentium Dual Core can cost around 200 zł (50$).

There is one issue with graphics cards for old computers for kernel 2.4. The price of old AGP graphic cards like GeForce 7 with 512 MB is high. You can be lucky and pay less than 150 zł (36$) if you are patient. On the other hand, you don't need to buy an expensive graphics card like GeForce 7 if you don't plan to play games like Quake 4. You can always buy Geforce 6 with 512 MB or Geforce 7 with 256 MB.

I highly recommend choosing computers with Sound Blaster Live 5.1. They work even with Mandrake 7.2 from 2000. They work great with old games that support only OSS on Linux distributions with ALSA. In this case, sound in games works automatically without silly scripts like this one:

echo "wolfsp.x86 0 0 direct" > /proc/asound/card0/pcm0p/oss

Quoting: denyasisCompared to steam, which literally takes minutes (depending on download speeds), yeah using Steam/Proton is faster... And unlike an ancient unsupported OS, is actually still maintained to work on hardware made in the last decade.

Why should companies make native games Linux if Wine is so great?

Why don't you use Google Chrome/LibreOffice on Wine?

I'm pretty sure these applications work great on Wine.

I think Linux has a large group of users that don't respect companies that publish games for Linux. It's not a good way to convince companies.

It's always better to have an unsupported game for Linux than nothing.

Quoting: denyasisComparability layers and emulation are made to avoid having to use older distros and hardware for a reason. This is the reason.

Valve used Linux instead FreeBSD/Solaris because it had more native games and applications. They saw potential in Linux because of the support of HIB and Desura.

Compatibility layers and emulators are just tools for different operating systems. The availability of them didn't change almost anything on Linux or Mac.

People use them to run games for Windows, and they aren't perfect. It's just a slower way of going back from Linux to Windows. You can't convince yourself that Wine is better than Windows. It's impossible to support the majority of games for Windows without issues. Windows is cheap, and you have fewer problems with it than with Wine.

The retro community prefers to build old computers with Windows 98/XP/7 than switching to Linux with Wine.

I think they are right about it.

Last edited by gbudny on 6 July 2023 at 11:27 pm UTC

Quoting: gbudnyThe retro community prefers to build old computers with Windows 98/XP/7 than switching to Linux with Wine.

That's totally fine for the retro community. That's a fine hobby I used to do in my youth with an old 286.

Weren't necessarily talking about the retro community exclusively here. That's an extra hobby, not a requirement.

Quoting: gbudnyPeople use them to run games for Windows, and they aren't perfect. It's just a slower way of going back from Linux to Windows. You can't convince yourself that Wine is better than Windows

Correct and no one is making that argument that wine is better than windows or wine is perfect. I'm making the argument along with everyone else here, that using wine (and especially Proton) is easier than building a whole other PC.

Quoting: gbudnyWhy should companies make native games Linux if Wine is so great?

Why don't you use Google Chrome/LibreOffice on Wine?

I'm pretty sure these applications work great on Wine

A) As an dumb end user, I don't care. Wine can be a target environment for all I care. If I can play it on Linux, what am I missing out on exactly? I will admit that I'm probably in the minority in my sentiment: I'm not anti-windows or a native purist nor did I come to Linux for some ethical reasons.

B) I don't use Chrome or Libre Office. If I did, though, I don't need wine since it's native. I also don't need to buy an entire ancient computer to run them, so I'm not sure what your point is here. I think I'm missing it??

The retro scene is cool. My 286 was a daily driver for some games (and school) until 2002 (it caught on fire). Remember Beast? Awesome game!!

No one's trying to dis on your hobby, but it is a fact that wine is just easier for end users, like me. I don't have the literal space for multiple PC's, or the funds (yes it's cheap to find some parts, but wine is free), or the time to do the research of what parts have what support from what year.

There's also the advantages of modern emulation /compatibility layers on a modern system. For example, with Steam's in home streaming I can play Lemmings in my living room on a big screen with a controller while the PC sits in the bedroom on the other side of the house. I'm assuming that's prolly not possible with an XP1900+ system (I legit don't know, so if you can, I'd love to hear about it).

Linux as a whole doesn't have great legacy support. It's struggles to play native games that are less than 10 years old which is kinda sad especially compared to Windows legacy support for some apps that nears 25-30 years. Retro and Wine are solutions to that. Wine is easier for most ppl.

Quoting: gbudnyI think Linux has a large group of users that don't respect companies that publish games for Linux. It's not a good way to convince companies.

If and when there are companies publishing games that suit my tastes for Linux, I'm there in a heartbeat. Like what I suspect will be many, I'm not going to waste money on games that I don't want and don't enjoy just because they have native Linux support - that won't convince companies to bring content that I'm interested in to the platform. Supporting stuff that can be run on Linux by whatever means actually might work, though, because Linux users will show up in their stats.

That's not a matter of not respecting Linux game-publishers - it's just a simple matter of market-forces. If what a user wants isn't there, then there's nothing for them to actually buy.

Quoting: gbudnyIt's always better to have an unsupported game for Linux than nothing.

But thanks to Proton, the other option isn't nothing - it's playing the game anyway. Successful "Let's look at official Proton support." devs of today may well become the "Let's look at native support." devs of tomorrow. A very, very long game is being played here.

Quoting: gbudnyPeople use them to run games for Windows, and they aren't perfect. It's just a slower way of going back from Linux to Windows. You can't convince yourself that Wine is better than Windows. It's impossible to support the majority of games for Windows without issues. Windows is cheap, and you have fewer problems with it than with Wine.

I'm not too sure that trying to sell Windows to people on a site about gaming on Linux will work.

Personally, I've literally only ever had two games have problems with Proton, and both were resolved with a little time and without expense, and this was much easier than the alternatives. Everything else has always just worked, and for me personally that actually is better than Windows, because it means that I can play what I want and not use Windows. Technology is never perfect - it just has to do the job well enough and seamlessly enough and people are happy with it, and that's part of why Proton is so well-liked.

Quoting: denyasisLinux as a whole doesn't have great legacy support. It's struggles to play native games that are less than 10 years old which is kinda sad especially compared to Windows legacy support for some apps that nears 25-30 years. Retro and Wine are solutions to that. Wine is easier for most ppl.

This is very true, in my experience. Though on the other side of the coin, I remind myself that this is so that the non-gaming side of things can keep ticking along smoothly, which is important too.

Anyway, I've got a recent example of this. There's this wonderful puzzle-platformer game called Tanglewood, released in 2018. Strictly speaking it was made for the Sega Mega Drive, and all of the computer ports are wrapped in a customised emulator (though you're also allowed to pull the ROM out and run it however you wish). It has a native Linux version, but it already doesn't work, and it requires jumping through a couple of hoops to fix (ignore the suggestion that the problem is related to AMD hardware - it isn't, and seemingly happens on anything). I have to add this caveat every time I recommend the game to people.

I've actually bought it twice, once on GOG (I didn't have a Steam account at the time) and once on Steam in the current sale, because I'll be getting a Steam Deck sometime this year and I wanted the convenience of just having it on my Steam account without having to add a non-Steam game. And this time around, I didn't bother with the workaround to make it run - I just clicked three times to use Proton, instead, and it was much quicker than the troubleshooting the first time around.

Quoting: PenglingThis is very true, in my experience. Though on the other side of the coin, I remind myself that this is so that the non-gaming side of things can keep ticking along smoothly, which is important too.

100% agree!!

To add to your list, Dying Light and Metro 2033/34 were examples from my library. Both had issues running (if at all), but with Proton, it was flawless!!

Quoting: denyasisTo add to your list, Dying Light and Metro 2033/34 were examples from my library. Both had issues running (if at all), but with Proton, it was flawless!!

How old were the native versions when issues arose? From what I can see, it looks like Tanglewood's native version was broken within just two years!

Last edited by Pengling on 7 July 2023 at 12:43 pm UTC

Quoting: Pengling

Quoting: denyasisTo add to your list, Dying Light and Metro 2033/34 were examples from my library. Both had issues running (if at all), but with Proton, it was flawless!!

How old were the native versions when issues arose? From what I can see, it looks like Tanglewood's native version was broken within just two years!

You're right. Yours is a much more recent example. Metro redux was 2014 and Dying light was 2015. We also have numerous Feral Ports which, while the guild standard of the time, have significant issues today.

Quoting: gbudnyI think Linux has a large group of users that don't respect companies that publish games for Linux. It's not a good way to convince companies.

I mean no offense here, and I love the retro community, but how does building a 20 year old computer and operating system convince them to do that today? Hell, those studios and publishers likely don't even exist anymore!

Or to put it a different way... It took me just shy of a decade to save up and build my PC in 2019 (which I still use today).... Why do I need to source and build another PC from 2016 and load Ubuntu 16 on it play games from 6-7 years ago? Or in Pengling's case from 2018?

Companies are focused on the now (ironically kinda like Linux, lol). They see the number of ppl buying steam decks and expecting support and the number of proton users on desktop. Pengling put it better than me, but that will help out Linux the most in the future.