I was thinking that way in the past. But then, the only stable ABI is the win32 one.
The linux kernel one is very stable, but the libs ones isn't.
As soon as the dev ensure and cooperates with wine/proton to make it work nicely, i'm game.
Needing those old libs in linux is rather cumbersome, if at all possible. So having wine doing the translation layer is a really good thing. As it frees the devs to be able to focus on 1 plateform.
I also noted that the switch enabled a lot of linux native ports. That's also a nice side effect.
You can create portable apps on Linux that will work for years to come. Bundle everything except for very core libraries, even libstd++. Things to NOT bundle would be glibc and any opengl implementation. To make apps backwards compatible with older versions of Linux, compile the app on a system with the oldest glibc you wish to support (because glibc is forwards compatible, but not backwards compatible).
This never really works in practice, far too many variations and compilation differences between distros. The Linux Standard Base was an attempt to do this and it went.... no where.
> (because glibc is forwards compatible, but not backwards compatible).
I've lost count of times I've had "portable" binaries not work because I'm using a newer version of glibc and the binary was compiled for Ubuntu/Debian.
The only "standardised" way of making native Linux apps portable and "work for life" is to use the thing that worked in the server space, containers, Flatpak being the vendor-neutral and more widely supported for desktop apps.
Steam can already use bwrap (Flatpaks sandbox system) with its own runtime to accomplish this, but why bother when you can just target Win32 and have it work out the box.
Outside of graphic and input, game engines make use of very few native APIs compared to applications as they're made to be portable with consoles.
Proton has gotten so good now that this is less of an issue to me. I buy games on GOG and just load them into Steam with Heroic.
I actually will often get better performance doing it this way; Jupiter Hell, for example, has a native Linux port, but I almost exclusively play the Windows version on Linux. I'm not entirely sure why this is, maybe performance issues with OpenGL compared to the D3D->Vulkan pipeline.
Linux has so much fragmentation between distros and the like, the Windows API is ironically one of the easiest ways to get stuff working consistently on Linux. If you're playing games on NixOS, for example, you have to do extra work to get Linux versions working a lot of the time because NixOS kind of breaks dynamic-linking by default. If you play the windows versions on NixOS, it's often as easy as `wine myGame.exe`.
Your Steam Deck provides Windows API emulation so games coded to target Windows will run on it. As a Steam Deck owner, you are perpetuating Windows gaming.
The linux kernel one is very stable, but the libs ones isn't.
As soon as the dev ensure and cooperates with wine/proton to make it work nicely, i'm game.
Needing those old libs in linux is rather cumbersome, if at all possible. So having wine doing the translation layer is a really good thing. As it frees the devs to be able to focus on 1 plateform.
I also noted that the switch enabled a lot of linux native ports. That's also a nice side effect.