I'm very curious how widespread this advice is. It's a little sad & ironic to me if Proton is now entrenching Windows as the only target platform. I'm hoping this wasn't blanket advice Valve is handing out but really something specific to the team.
Very. Win32 ABI is the most stable and rock solid compared to the messy moving target of the Linux world, so recommending it is not entrenching Windows, just very good advice to save time and resources to target a platform that's alredy known and stable, and since the target is fixed and well known, it makes it also very easy to emulate on their end for Linux.
As much as FOSS-Linux evangelists hate it, Win32 emulated on Linux is better for everyone, than tryin to port games natively on Linux, and makes the most business sense of you want the same games on Linux.
I'm not the smartest tool in the shed, but I was not trying to be snarky and undermine your superiority or downplay your question, I was just saying it doesn't matter as the end goal is to get Windows games playable on Linux, and for that Proton emulation is the way that makes sense financially and practically for both developers and gamers, so no need to dive into the codebases and compare them, just to prove a point that's moot from the get-go.
The Win32/low-level Windows programmers I know still just refer to it as "Win32", though.
Blatant lie bordering on disinformation.
The only reason it is a "stable ABI" is that every dev of every windows program bundles every library with their program. You could do the same thing on Linux and the stability "story" would be exactly the same, or in fact even better on Linux because Win32 isnt actually stable and the Linux system call ABI is.
What does "no they don't" mean? People absolutely do bundle all their dependencies on Windows that aren't part of the stable platform guaranteed to be around forever.
On Linux the part of the stable platform guaranteed to be around forever the system call ABI.
If you bundle DLLs with your program then you have a stable ABI automatically, because it's constant: something you bundle will never change its ABI, because it won't change in any way, because it's bundled. It's constant. Windows developers bundle all their dependencies with their programs. The result is that they don't have issues with their programs not working because the libraries they depend on have changed since they released the program. They might as well be statically linked.
There is nothing Windows-specific about doing this. You can statically link libraries on Linux and you can dynamically link to libraries that you bundle with your program. There's nothing stopping you from doing exactly the same thing that people do on Windows, and it will be just as stable.
The difference between the platforms is that Windows people do this and Linux people don't, I think mostly because they don't properly understand what a platform is in the Linux world. "Linux" as a platform is the kernel, and nothing else. You can't rely on any userspace libraries existing, not even libc. Or you could target glibc+Linux. That's a different platform, where you can assume that libpthread.so, libm.so, libdl.so and libc.so all exist, and some others. But you can't assume GTK+ will exist. Or you can target a particular distribution at a particular version. Then you are reliant on the particular distribution's stability guarantees. You can't expect it to run elsewhere, but you get access to a much wider array of libraries that you can expect to exist (by making non-base libraries dependencies of your RPM).
In all cases, ABI stability (the ability to update dependencies without rebuilding) is a property of the platform you target. To rely on a stable ABI, everything you target needs to provide that ABI stability. If you target a distribution like RedHat Enterprise Linux, then you get 10 years of ABI stability guaranteed. If you target Arch Linux, you don't: as far I understand, every package that depends on a library is expected to be rebuilt when the library is updated, if necessary. If you target Linux itself, or glibc + Linux, then you get ABI stability forever, and they go to extremes to give you that. But in turn you need to bundle any dependencies yourself, by whatever means you like. That doesn't mean you can't update those bundled dependencies when you update the program, of course.
In the gaming world where steam installs apps itself and you need the Windows version for commercial viability anyways, it does make sense to push them to win32.
Outside of gaming though, I don't really see this being the case. You random desktop apps are better off with flatpak and distros like Fedora are already moving everything that direction. Flathub also has the benefit of allowing devs to push to one repo and support multiple distros (again, like Steam).
It's all Linux containers/namespaces after all.
That's bullshit, for game developers there shouldn't be any "messy moving target" outside of the Steam Linux Runtime[1], which is pretty much rock solid.
[1] https://gitlab.steamos.cloud/steamrt/steamrt/-/blob/steamrt/...
I’m dead serious. Grab a copy of Nautilus or GNOME Files from Ubuntu 16.04; try running it on Ubuntu 22.04. It isn’t easy. Now imagine a game.
As for “just get the libs,” that’s hilariously easier said than done. Try my example - it’s enough to make an engineer cry.
* if u dont sandbox this a bit with custom lib paths
What I am disputing is how this comes off to a game developer; 5 years from now, heck, 2 years from now when their games require library surgery to keep running... that’s just an awful experience.
That is not what a developer would consider a stable ABI. They could look into Flatpak - but look at what’s trending on Hacker News today - a rant against Flatpak.
Win32 over Proton is the winner for them; all other proposed solutions are hilariously naive and optimistic to what game development requires. No game developer is ever going to individually package, and consistently repackage, their game for 20 distributions. That’s never going to happen.
>No game developer is ever going to individually package, and consistently repackage, their game for 20 distributions. That’s never going to happen.
Nobody has suggested they should.
Nor do they. Steam Linux Runtime exists.
XLib is tiny by modern standards.
my memory might be wrong but I had issues with native linux games that had level editor based on GTK and python, could not get them to run after 3 years since launch, I do not claim it is impossible just that I could not do it with some a few hours effort.
Windows is the opposite: the only stable ABI is the dynamically linked user space ABI. So yes, it’s perfectly possible to have a stable dynamic ABI across a dynamically linked boundary.
... to the kernel. So not the opposite at all. In fact exactly the same.
This is the point of difference: the layer at which each is stable. NOT whether Linux is stable.
The two approaches are definitively not the same (as you claim), and the significant shortcomings of Linux's approach are why Win32 is becoming the ABI devs target even on Linux.
This is not true. If your target platform is a distribution then you can assume that distribution's guarantees hold true.
What you cannot do is target "GNU/Linux" broadly and assume every glibc-based system running on top of the Linux kernel has all the libraries you want to depend on.
Pick a platform and target it. That can be the kernel. That can be glibc+the kernel (hey look GNU/Linux really is useful terminology), that can be RHEL9 or it can be Debian xyz. But don't pick "Linux" then make assumptions about userspace.
Are you under some weird delusion that you are forced on Linux to develop software in one particular way?
The packages pulled in by steam define a bunch of vulkan providers which then confuses steam. Many games won't even launch and you have to manually kill off a bunch of steam worker processes to even successfully shutdown and restart steam. You can't uninstall the package due to dependencies, so instead have to manually move/rename some files under /usr/share/vulkan/icd.d/ to only leave the one for NVIDIA.
Then, games launch but have very inconsistent performance. I don't know if this is because Optimus is competing with the game for PCIe bandwidth, or something else still going awry with the driver stack.
Evangelism is useless in the face of results.
This is meaningless if you change the definition of "on Linux" to mean "on Windows".
There are more functioning games on Linux than I ever would have thought possible because of this (very difficult and certainly open source) work that’s been done by Wine, Proton, Valve and many many more. But of course, someone has to find a way to discourage all of that because it isn’t pure enough or whatever.
https://github.com/GloriousEggroll/wine-ge-custom
Personally, I've been using Windows fully offline with GOG games, although I'd like to some day try putting together a Linux based offline game console (or maybe NetBSD based if Wine is sufficient).
I still prefer they go with the proton approach though.
As such, this is a mixed bag. Actual users that cut support issues from random machines will be worth trying to engage with. General cries that you should support it with no payment in play should likely be ignored, though.
I tried Overwatch 2 with Proton and performance was abysmal. My computer seemed to be melting and FPS was jumping all over the place.
It does 144fps on Windows 11 without sweating (same PC).
In my experience, I had no problem playing Overwatch 1 at 144fps through Proton on my 1050ti.
But I think of the steam deck which is basically a Linux PC. Its lowerer spec, low power, but it seems to run pretty well without terrible battery life.