Linux ecosystem contributions from SteamOS

Posted Oct 5, 2023 19:45 UTC (Thu) by Cyberax (✭ supporter ✭, #52523)
In reply to: Linux ecosystem contributions from SteamOS by dullfire
Parent article: Linux ecosystem contributions from SteamOS

> This is true for win32 as well. As soon as you use stuff that's out of scope... the ABI stability no longer applies[1]. I will also note that most windows games are not (directly) written for the win32 ABI. Most windows games use some sort of toolkit. Directx was common (I think it still is, but I've long been out of windows dev).

DirectX can be considered a part of the Win32 ABI. It's incredibly backwards-compatible. You can still launch games written for DirectX 6, present in Win98. It did deprecate several components (DirectPlay, DirectShow), but the core graphics and sound components are still compatible all the way back to the previous millennium.

> This is the rough analogy of, in a pure windows environment, porting a win32/MFC program to SDL1.2, then later, having only SDL2.0 installed, whining that it wont compile or run.

It's not just SDL, it's more like QT or GTK. Can you run a program written for GTK 1.2 now?

> Maybe this biggest complaint here is that the FLOSS ecosystem has no single "core do-everything" ABI. But, that is more or less by consensus.

It's not by "consensus". It's mostly because anything above the most basic layer is fragmented to hell.

> [2] remember AMD64 came out around 2001 IIRC, so w/e ABI's most people use for their current desktops probably didn't even exist in the 90s or before.

Microsoft still fully supports 32-bit apps! Even on ARM64 platforms via emulation. Think about this: games written in the early 2000-s for a 32-bit architecture, still can work on most recent Windows running on a completely different architecture.

They are not perfect, of course. Nothing is. But Microsoft really tries to keep the old running. And the importance of this is something that Linux ecosystem only now is starting to realize.

Linux ecosystem contributions from SteamOS

Posted Oct 5, 2023 22:38 UTC (Thu) by pizza (subscriber, #46) [Link] (1 responses)

> They are not perfect, of course. Nothing is. But Microsoft really tries to keep the old running. And the importance of this is something that Linux ecosystem only now is starting to realize.

Of course, it helps to have a multi-billion-per-year desktop monopoly funding (and directing) the developers ensuring this backwards compatibility continues.

Linux ecosystem contributions from SteamOS

Posted Oct 6, 2023 3:42 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

That's most definitely a factor. Yet I think that the Linux ecosystem as a whole has only recently started taking ABI backwards compatibility seriously.

Probably just in time for the classic desktop to become irrelevant.

Linux ecosystem contributions from SteamOS

Posted Oct 6, 2023 11:11 UTC (Fri) by farnz (subscriber, #17727) [Link] (2 responses)

There's also a little bit of legacy that resulted in MS taking ABI seriously at a time when open source just didn't care; DLL Hell.

DLL Hell had a lot of contributing factors that weren't present on *nix systems of the same era; first, imports from DLLs could be done by ordinal instead of by name, which meant that if a new version of the DLL didn't retain the same ordinal positions for all functions as the previous version (e.g. because ordinal choice depended on symbol order in the object files), you'd have problems. Worse, the runtime linker couldn't tell that you weren't expecting the function to be different - all it knew is that you'd asked for symbol #4, and that's what it gave you; in contrast, on ELF systems, symbol lookup is always by name, so the runtime linker could say "you asked for print_magic_output, but the library does not contain that symbol".

Add in the single address space of Win16 (so one bad program could take out the entire system), and the fact that there was rarely a separate sysadmin maintaining the platform (so you had non-technical users doing crazy things based on half-understood rumours, not solid understanding of the system), and you had a problem that could only be solved by thinking hard about ABI and getting it right.

Linux ecosystem contributions from SteamOS

Posted Oct 6, 2023 16:42 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Ah yes, I remember.

Microsoft decided to be very careful with DLLs. They are still extremely limited compared to ELF shared libraries. It's hard to do circular dependencies, and all the exports must be clearly marked.

I remember our Linux guys laughing at my Windows code because I had to add "__declspec(dllexport)" in all kinds of places. By default, Unix shared objects just export everything. Now it's pretty clear that this kind of explicit exports makes shared objects way more reliable.

Linux ecosystem contributions from SteamOS

Posted Oct 6, 2023 18:17 UTC (Fri) by andresfreund (subscriber, #69562) [Link]

I agree that exporting all symbols by default was a bad idea. But the macro magic required to switch between declspec(dllexport) and declspec(dllimport), depending on whether you build or consume a library, is also fairly ridiculous.

Linux ecosystem contributions from SteamOS

Posted Oct 17, 2023 8:51 UTC (Tue) by NAR (subscriber, #1313) [Link]

Think about this: games written in the early 2000-s for a 32-bit architecture, still can work on most recent Windows running on a completely different architecture.

Well, I have Civilization IV on CD from 2005 and it doesn't work - the copy protection depends on some kind of service that's no longer included since Windows 10.