[1] Case in point: glibc's compatibility guarantees are weaker than what you get on Windows. (For instance, your system's glibc cannot be older than what a game is built against, which may present problems for devs using Fedora/Arch and players on Debian/LTS Ubuntu, something I've experienced first-hand for my apps.) The X11 to Wayland migration is also still underway. (Though things are getting better, the attitudes of some Wayland maintainers are a bit concerning: "I don't [care] what you think is normal behavior for games. You get certain guarantees with wayland. Deal with it. If clients decide to do exactly what they do on windows or X11 they won't work correctly." [3] I'm not sure game developers would enjoy such reception.)
[2] https://store.steampowered.com/hwsurvey
[3] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18...
Windows is going to end up as the 2030s version of dosbox
edit: as in Windows ends up with the same fate as MS-DOS: replaced with a piece of software analogous to dosbox
Porting games from Android/NDK into GNU/Linux is relatively a child's play.
Playstation OS is also POSIX friendly.
Finally every serious middleware engine supports GNU/Linux.
Still the amount of studios that care about GNU/Linux is almost zero.
With Valve, there are no reasons to bother at all as a studio, target Windows/DirectX, let Valve do the work, collect the money with zero additional effort.
Now with Windows based handhelds, Valve will learn what happened to netbooks.
Imagine games that dynamically link some library (or glibc). They wouldn’t run on other Linux distributions with mismatching dependencies (or a different libc).
Sure, 100% statically linked binaries might work. But wine also runs on non-Linux.
Windows is a sufficiently homogeneous target, and wine works well enough. Heck, some games run better in Linux+Wine than they do in windows.
What do I need to make a video game? Input, sound, graphics. What use is a shell, a userland, or even a C library (if I'm not writing in C) for making a video game?
Android is _not_ GNU/Linux. It doesn't need to provide a shell or userland as part of the platform, and its C library is bionic not glibc. It also provides a lot of things GNU doesn't*, like input, sound, and graphics. It's also not designed to run on a desktop, and the differences between mobile and desktop are non-trivial and slowly growing.
Windows and macOS are full graphical operating systems. Linux is just a kernel. GNU/Linux is just a command-line operating system. Great for servers, terrible for video games.
Moreover, commercial video games are distributed in binary format, not source. Even if input, sound, and graphics were solved on Linux in a consistent way, the developers** can't help but break ABI compatibility every couple of years. Many apps from Windows 3.1 days can still run on Windows 11. What binary from Linux's early days can still run today, never mind with graphics or sound?
* = You could include GLib/GTK+/GNOME but then you're targeting a specific desktop environment and not simply "Linux" or even "GNU/Linux" anymore
** = Except for the kernel developers, upon whom Linus forces "never break userspace" as a hard rule
Honestly, somebody could have done something like this for "native" Linux but the incentives never really fell into place. It could even have been Valve, but I would guess they weighed the options and found this to be the one that gave them the widest compatibility without expecting too much of the game developers, many of whom were reluctant to make their games available on Steam at all.
I believe pjmlp's point (although it requires a fair bit of reading between the lines) is that Windows already has fantastic backwards compatibility (as you elaborated on), and Valve's work has created a situation such that all developers need to do is target and build for only Windows, release Windows-only binaries; then, Valve/WINE will do the hard work in ensuring they run seamlessly on Linux. This means developers don't need to care about building natively for Linux (à la Factorio and a tiny handful of other games). In other words as another commenter said, the real stable ABI on Linux is Win32 + WINE.
Furthermore, Valve's work also negates the work of open-source engine and game developers who have ported their engines and games to native Linux. This is because developing for Windows is a known quantity, and there is an overwhelming volume of resources, effort, and experience in writing games for Windows.
pjmlp concludes with 'Now with Windows based handhelds, Valve will learn what happened to netbooks', which I gather to mean that the Steam Deck will lose popularity to Asus and MSI's (and soon, other manufacturers too) handheld systems, since running most games directly on Windows is still easier than the occasional faff that someone has to do when running games on WINE/Proton.
It's a riff on only stable OS API on Linux is Win32.
The comparison with OS/2 only applies at a very surface level - and isn't even the whole reason why OS/2 failed when it had to compete with Windows. Among other things:
1. OS/2 could only run 16bit Windows applications at a time when Windows was switching to 32bit. Even the 16bit Windows applications were not 100% compatible and that is despite using Microsoft's code.
2. OS/2 had much worse hardware support than Windows as everyone was targeting Windows. On the other hand IBM as a whole never put much effort towards OS/2.
3. OS/2 Windows support had applications either run inside an isolated environment or they looked "alien" next to OS/2 applications at a time when GUIs were still trying to look consistent. While this is also the case with Wine/Proton, the focus on games makes this point moot (and people do not seem to care as much about GUI consistency these days).
> Now with Windows based handhelds, Valve will learn what happened to netbooks.
So far every single Windows handheld review i've seen that compares it to Steam Deck mentions both how the UX is worse than Steam Deck and games are -ironically- more likely to have issues on the Windows-based one. The only two saving graces for Windows handhelds is that they tend to be faster (but only when running at full throttle which limits their battery lifetime - Steam Deck runs faster at lower watts for better battery lifetime) and that anticheat rootkits work on the Windows handhelds whereas they do not work on Steam.
And you also forget that Valve did try to get game developers target Linux and put a lot of effort in the ecosystem for literally years before making Proton, yet developers largely ignored that.
I'd say win32/flatpak/libretro are the only sane way for games to target linux right now. The fact that linux doesn't have real "runtime" and major components required by games link against libc is what makes linux really unstable for anything that needs to open window, draw stuff using GPU and play audio. It's possible to create static binaries for linux that work for eternity, thanks to kernel being actually stable. But link against something in /usr/lib and it all goes to hell. If the GPU drivers and libs that provided basic window / audio did not depend on libc and were standalone, the situation would be much better. Here's good video about this problem space btw https://www.youtube.com/watch?v=pq1XqP4-qOo
Microsoft is already half way there with WSL, as soon as they realised folks rather buy Apple gear for UNIX experience, instead of supporting Linux OEMs.
"Runs Windows better than Windows" didn't work last time, and won't now.
And if XBox really goes full speed ahead as cross platform brand, as the console rumor mill has been discussing, lets see how many Microsoft owned studios stuff keep landing on Steam.
It already works, i play games every day, pretty much all games i play are Windows games and i can count on my hands the number of times i booted on actual Windows the last three years.
It suffices for Game Pass and Epic Store to be more appealing to studios targeting Windows, plus all Microsoft owned studios being taken out of Steam.
SDL2 is a great library, and many good games have been built using it. But then your target platform is not Android at all, it's SDL2's platform-agnostic abstractions (plus OpenGL or Vulkan if you're doing 3D graphics). And you still may run into input handling issues if you didn't think carefully about the differences between mobile and desktop.
Then, to achieve something like the binary compatibility Windows already provides, you'll need to statically link your executable on Linux. That definitely means no GNU because virtually no game developer is going to allow themselves to be forced onto a copyleft license.
Even on macOS, which sits between Windows and Linux in terms of stability and user base, the selection of available games is about 10-20% of my library. Apple dropping support for 32-bit x86 (only to kind of resurrect it with Rosetta 2 on M1/M2/+) and only barely supporting OpenGL anymore while refusing to support Vulkan at all doesn't help. Credit again to Factorio for porting to macOS/ARM64, but they're once again in the small minority.
There's an interplay here between user-driven demand and platform-provided stability. As much of a faff as Wine/Proton can be, writing a game to properly support, say, Wayland is worse. That's a problem Valve _could_ help fix, but won't do anything for the vast majority of existing games.