6 ms·

Win32 Is the Only Stable ABI on Linux

39 points by sedatk 1y ago

throwaway2046 1y ago
This should be updated to include the GLIBC libcrypt fiasco.
drnick1 1y ago
Game devs should 100% focus on making sure their game runs flawlessly on Proton instead of releasing a half-assed Linux version. This is what Valve has infamously done with games such as Left 4 Dead 2, whose Linux version has multiple game-breaking bugs that have been known for over 15 years. Unfortunately that game does not run on Proton because of an obscure VAC bug that Valve hasn't bothered to fix since they can already claim Linux compatibility through their terrible Linux port.
- john01dav 1y ago
  Game devs should just design their games to be cross platform from the start, thus making this problem go away. Every major language compiles everywhere, so all that you need to do is not use libraries that tie you to a specific OS. When I test on the OSes that I'm not developing on I usually find a few bugs to work out, but never anything major. DirectX is the main thing to avoid, so I use Vulkan for my graphics work. From when I first got into graphics, I immediately dismissed DirectX because of platform locks. I wish that more developers had this same stance of refusing all options with abusive practices like platform exclusivity.
  - pjmlp 1y ago
    Consoles only do C, C++ and Assembly, C# does it via IL2CPP or in-house compilers, so not "every major language compiles everywhere". Games industry is built on platform locks and exclusives since the Atari 2600.
    - john01dav 1y ago
      > I wish that more developers had this same stance of refusing all options with abusive practices like platform exclusivity. I don't touch consoles. They're cesspits of abusive practices: computers that can't do general purpose computing, shit like xbox demanding a monthly fee to have networking capabilities, and, of course, the fact that you need permission from the console's manufacturer to make games for them. Steam deck is an exception. They do consoles how it should be done. (I will touch such technologies when being paid to do so, after expressing my concerns about them if applicable)
- pjmlp 1y ago
  Until Proton becomes another OS/2, "runs Windows better than Windows". Just wait until all the PC handelds start shipping the better Windows version, like it happened with netbooks.
  - sph 1y ago
    > runs Windows better than Windows It already does. When Elden Ring released, it suffered from terrible performance problems, which were worked around in VKD3D (DX12 for Wine) in the first week of release. I've heard people complaining about Elden Ring performance on Windows for months afterwards.
    - pjmlp 1y ago
      OS/2 also did, until it did not. The point is the historical lesson of building castles on other companies kingdoms, not the technical achievement.
      - surajrmal 1y ago
        But Linux offers more value beyond running games written for Windows so the analogy doesn't hold.
        rnd0 1y ago
        OS/2 was more stable than Windows and it had threaded application support -so the analogy does hold, IMO.
        dfe 1y ago
        OS/2 did offer a lot of value beyond just running Windows software. The WPS (Workplace Shell) is to this day one of the better desktop UIs. It brought a lot of the classic Macintosh feel to the PC world and improved upon it. Where Windows only vaguely looked like a Macintosh, OS/2 had things like a spatial filer so it felt a lot more like a Macintosh on steroids. It had neat ideas like "template files" and a bunch of other stuff I can't even remember. On the non-GUI front it had a better command processor, CMD.EXE, which is a precursor to the Windows NT one. It had an actually decent scripting language (REXX). It had a better filesystem (HPFS). It was also incredibly good at running DOS games of the era, while comfortably multitasking in the background, including serial port and network usage. You could be downloading something while fragging some demons in Doom. You could also pause the game at any time and switch back to the desktop, then go back and resume. The thing that was different between OS/2 and Linux + WINE is the engineering approach. IBM had a license to use actual DOS and Windows code, at least until they cancelled the JDA (Joint Development Agreement) contract with Microsoft in 1990. Even after they cancelled, they still had rights to everything from before, which included Windows 3.0. In order to avoid having to pay Microsoft a royalty on the Windows portions of OS/2, which they had to pass along in the retail price, they even released a variant of OS/2 version 2.1 called "OS/2 for Windows" which took your existing Windows 3.x, the one that you almost certainly already paid for as part of your computer, and binary patched it to work under OS/2. There was some grousing when Windows 3.11 came out and broke it, but IBM issued a patch. So, in essence, they were able to market OS/2 less like a replacement OS, and more like a utility program you added on to your existing system to make it behave better. Kind of like hey, you just dropped $2000-$3000 or more on a new system, what'a another $129 to make it really sing. And because it leveraged the fact that you already paid for Windows when you bought the computer, compatibility was top-notch: it was actually running real Windows. In my opinion as a user at the time, what killed it was the move to Win32 software which OS/2 couldn't run but Windows 95 could. Once computers started regularly coming with enough RAM to run Windows NT 4, the nice things about OS/2 just weren't enough to justify the inability to run basically every new software package.
deleted 1y ago
[deleted]
deleted 1y ago
[deleted]
serbuvlad 1y ago
This is not an ABI stability problem, this is a UX problem. iOS and Android do backwards incompatibility all the time. If you find a mobile app that hasn't been updated in 10 or 15 years, you won't be able to install it on a modern device. But, iOS and Android ship apps to billions of users, nobody complains about ABI stability and nobody uses a Win32 compatibility layer. glibc already has decent UX in that it doesn't allow you to load an app built for a newer version on a host with an older version. Unfortunately, the message is not user friendly at all "could not load @@GLIBC_X.YZ@@foo()", instead of something more readable, but the restriction is, in itself, good. The problem is that there is no system to trigger backwards incompatibility at any point, nor is there a simple way to target an older Glibc version without spinning up a docker container. And glibc is a HELL of a codebase, I would NOT want to be responsible for implementing those features, so I understand why they're not there. But 'our Linux build for our game we are still selling and advertising as working on Linux is no longer compatible with new Linux distributions, so let's rebuild it' is a much easier decision for a developer, publisher, etc. to make than '"some" Linux users are reporting issues with our game, should we dedicate resources to investigating this?'
- throwaway2046 1y ago
  > glibc [...] doesn't allow you to load an app built for a newer version on a host with an older version > the restriction is, in itself, good. Why do you consider this a good restriction?
  - serbuvlad 1y ago
    Because if function foo's third flag parameter supports FOO_ENABLE_FEATURE_X starting from 2.31, and a program only occasionally calls foo with this flag, there is no good way to detect this incompatibility on a 2.30 system at link time. The restriction is only annoying because there is no way to trivially link against an older "minimum requirement" ABI.
- saurik 1y ago
  > nor is there a simple way to target an older Glibc version without spinning up a docker container ? I feel like you might be falling into the trap of assuming that the compiler always targets the current running system, but you 100% should always always always be doing a Linux-to-Linux "cross" compile with a sysroot... you don't need a docker container: you just extract an old Linux distribution into a folder and tell your current/modern compiler to target it.
dustbunny 1y ago
I shipped godot games on Linux and it just worked. Maybe some people had some issues but it never surface to me. As usual I feel like people make it sound worse than it is. It's not like a barren wasteland of broken apps on Linux.
Iwan-Zotow 1y ago
Huh?!? Syscalls are stable ABI on Linux, this is why docker works
- dcrazy 1y ago
  It’s a tongue in cheek comment, but the author does say: > Personally I share Linus’ opinion (link to YouTube) that changing ABI is okay as long as no one has noticed, but once it gets noticed - then it’s a regression. Once it’s a thing people depend on, it becomes a feature.
- sph 1y ago
  Not much software directly targets syscalls. Even just linking to libc (musl/glibc) exposes you to the churn of userspace linux. Games depend on the entire stack (audio, HID, VR, Vulkan, desktop compositor choice, etc.) so are the most vulnerable to any minor change. And game developers, rightly so, have better things to do than to recompile if not re-port their game because Linux has decided that Pulseaudio is out, or X11 has been replaced with Wayland. So yes, in practice, there are only two stable APIs/ABIs on Linux: the syscalls, and Proton.
  - Iwan-Zotow 1y ago
    "Even just linking to libc (musl/glibc) exposes you to the churn of userspace linux" Sure, but this is why sometimes people pack libc/libm into docker and had it running w/o problems - because for any decent kernel syscalls are stable ABI.
deleted 1y ago
[deleted]
abstractspoon 1y ago
Them's fightin' words
lordkrandel 1y ago
Wait, I remember Silverlight... do you?
nateb2022 1y ago
(2022) Previous discussion: https://news.ycombinator.com/item?id=32471624 https://news.ycombinator.com/item?id=32471624

39 points by sedatk 1y ago

throwaway2046 1y ago

This should be updated to include the GLIBC libcrypt fiasco.

Game devs should 100% focus on making sure their game runs flawlessly on Proton instead of releasing a half-assed Linux version. This is what Valve has infamously done with games such as Left 4 Dead 2, whose Linux version has multiple game-breaking bugs that have been known for over 15 years. Unfortunately that game does not run on Proton because of an obscure VAC bug that Valve hasn't bothered to fix since they can already claim Linux compatibility through their terrible Linux port.

john01dav 1y ago
Game devs should just design their games to be cross platform from the start, thus making this problem go away. Every major language compiles everywhere, so all that you need to do is not use libraries that tie you to a specific OS. When I test on the OSes that I'm not developing on I usually find a few bugs to work out, but never anything major. DirectX is the main thing to avoid, so I use Vulkan for my graphics work. From when I first got into graphics, I immediately dismissed DirectX because of platform locks. I wish that more developers had this same stance of refusing all options with abusive practices like platform exclusivity.
- pjmlp 1y ago
  Consoles only do C, C++ and Assembly, C# does it via IL2CPP or in-house compilers, so not "every major language compiles everywhere". Games industry is built on platform locks and exclusives since the Atari 2600.
  - john01dav 1y ago
    > I wish that more developers had this same stance of refusing all options with abusive practices like platform exclusivity. I don't touch consoles. They're cesspits of abusive practices: computers that can't do general purpose computing, shit like xbox demanding a monthly fee to have networking capabilities, and, of course, the fact that you need permission from the console's manufacturer to make games for them. Steam deck is an exception. They do consoles how it should be done. (I will touch such technologies when being paid to do so, after expressing my concerns about them if applicable)
pjmlp 1y ago
Until Proton becomes another OS/2, "runs Windows better than Windows". Just wait until all the PC handelds start shipping the better Windows version, like it happened with netbooks.
- sph 1y ago
  > runs Windows better than Windows It already does. When Elden Ring released, it suffered from terrible performance problems, which were worked around in VKD3D (DX12 for Wine) in the first week of release. I've heard people complaining about Elden Ring performance on Windows for months afterwards.
  - pjmlp 1y ago
    OS/2 also did, until it did not. The point is the historical lesson of building castles on other companies kingdoms, not the technical achievement.
    - surajrmal 1y ago
      But Linux offers more value beyond running games written for Windows so the analogy doesn't hold.
      - rnd0 1y ago
        OS/2 was more stable than Windows and it had threaded application support -so the analogy does hold, IMO.
      - dfe 1y ago
        OS/2 did offer a lot of value beyond just running Windows software. The WPS (Workplace Shell) is to this day one of the better desktop UIs. It brought a lot of the classic Macintosh feel to the PC world and improved upon it. Where Windows only vaguely looked like a Macintosh, OS/2 had things like a spatial filer so it felt a lot more like a Macintosh on steroids. It had neat ideas like "template files" and a bunch of other stuff I can't even remember. On the non-GUI front it had a better command processor, CMD.EXE, which is a precursor to the Windows NT one. It had an actually decent scripting language (REXX). It had a better filesystem (HPFS). It was also incredibly good at running DOS games of the era, while comfortably multitasking in the background, including serial port and network usage. You could be downloading something while fragging some demons in Doom. You could also pause the game at any time and switch back to the desktop, then go back and resume. The thing that was different between OS/2 and Linux + WINE is the engineering approach. IBM had a license to use actual DOS and Windows code, at least until they cancelled the JDA (Joint Development Agreement) contract with Microsoft in 1990. Even after they cancelled, they still had rights to everything from before, which included Windows 3.0. In order to avoid having to pay Microsoft a royalty on the Windows portions of OS/2, which they had to pass along in the retail price, they even released a variant of OS/2 version 2.1 called "OS/2 for Windows" which took your existing Windows 3.x, the one that you almost certainly already paid for as part of your computer, and binary patched it to work under OS/2. There was some grousing when Windows 3.11 came out and broke it, but IBM issued a patch. So, in essence, they were able to market OS/2 less like a replacement OS, and more like a utility program you added on to your existing system to make it behave better. Kind of like hey, you just dropped $2000-$3000 or more on a new system, what'a another $129 to make it really sing. And because it leveraged the fact that you already paid for Windows when you bought the computer, compatibility was top-notch: it was actually running real Windows. In my opinion as a user at the time, what killed it was the move to Win32 software which OS/2 couldn't run but Windows 95 could. Once computers started regularly coming with enough RAM to run Windows NT 4, the nice things about OS/2 just weren't enough to justify the inability to run basically every new software package.

deleted 1y ago

[deleted]

deleted 1y ago

[deleted]

serbuvlad 1y ago

This is not an ABI stability problem, this is a UX problem. iOS and Android do backwards incompatibility all the time. If you find a mobile app that hasn't been updated in 10 or 15 years, you won't be able to install it on a modern device. But, iOS and Android ship apps to billions of users, nobody complains about ABI stability and nobody uses a Win32 compatibility layer. glibc already has decent UX in that it doesn't allow you to load an app built for a newer version on a host with an older version. Unfortunately, the message is not user friendly at all "could not load @@GLIBC_X.YZ@@foo()", instead of something more readable, but the restriction is, in itself, good. The problem is that there is no system to trigger backwards incompatibility at any point, nor is there a simple way to target an older Glibc version without spinning up a docker container. And glibc is a HELL of a codebase, I would NOT want to be responsible for implementing those features, so I understand why they're not there. But 'our Linux build for our game we are still selling and advertising as working on Linux is no longer compatible with new Linux distributions, so let's rebuild it' is a much easier decision for a developer, publisher, etc. to make than '"some" Linux users are reporting issues with our game, should we dedicate resources to investigating this?'

throwaway2046 1y ago
> glibc [...] doesn't allow you to load an app built for a newer version on a host with an older version > the restriction is, in itself, good. Why do you consider this a good restriction?
- serbuvlad 1y ago
  Because if function foo's third flag parameter supports FOO_ENABLE_FEATURE_X starting from 2.31, and a program only occasionally calls foo with this flag, there is no good way to detect this incompatibility on a 2.30 system at link time. The restriction is only annoying because there is no way to trivially link against an older "minimum requirement" ABI.
saurik 1y ago
> nor is there a simple way to target an older Glibc version without spinning up a docker container ? I feel like you might be falling into the trap of assuming that the compiler always targets the current running system, but you 100% should always always always be doing a Linux-to-Linux "cross" compile with a sysroot... you don't need a docker container: you just extract an old Linux distribution into a folder and tell your current/modern compiler to target it.

dustbunny 1y ago

I shipped godot games on Linux and it just worked. Maybe some people had some issues but it never surface to me. As usual I feel like people make it sound worse than it is. It's not like a barren wasteland of broken apps on Linux.

Iwan-Zotow 1y ago

Huh?!? Syscalls are stable ABI on Linux, this is why docker works

dcrazy 1y ago
It’s a tongue in cheek comment, but the author does say: > Personally I share Linus’ opinion (link to YouTube) that changing ABI is okay as long as no one has noticed, but once it gets noticed - then it’s a regression. Once it’s a thing people depend on, it becomes a feature.
sph 1y ago
Not much software directly targets syscalls. Even just linking to libc (musl/glibc) exposes you to the churn of userspace linux. Games depend on the entire stack (audio, HID, VR, Vulkan, desktop compositor choice, etc.) so are the most vulnerable to any minor change. And game developers, rightly so, have better things to do than to recompile if not re-port their game because Linux has decided that Pulseaudio is out, or X11 has been replaced with Wayland. So yes, in practice, there are only two stable APIs/ABIs on Linux: the syscalls, and Proton.
- Iwan-Zotow 1y ago
  "Even just linking to libc (musl/glibc) exposes you to the churn of userspace linux" Sure, but this is why sometimes people pack libc/libm into docker and had it running w/o problems - because for any decent kernel syscalls are stable ABI.

deleted 1y ago

[deleted]

abstractspoon 1y ago

Them's fightin' words

lordkrandel 1y ago

Wait, I remember Silverlight... do you?

nateb2022 1y ago

(2022) Previous discussion: https://news.ycombinator.com/item?id=32471624 https://news.ycombinator.com/item?id=32471624