[forrestthewoods]

> Wine and Proton are not tributes to Win32's portability.

I emphatically disagree. It is a hilarious and catastrophic failure of Linux userspace that the best API for running games on Linux is Win32. This has absolutely nothing to do with what Microsoft locking down the desktop market. It has 100% literally everything to do with Linux userspace being a clusterfuck of terrible design.

Linux adopted Win32 because it actually worked. They didn't have to. They could have simply invented a better API that didn't suck. But that's quite hard.

So yeah. I emphatically, but respectfully, disagree with your entire thesis.

[ravenstine]

It's Linux's failure that one of the world's biggest corporations outspent it on marketing by orders of magnitude? You can sell crap like hotcakes with enough money and advertising minds. Yours isn't really an argument for Linux APIs being any worse or better quality.

> Linux adopted Win32 because it actually worked.

WINE would have been invented one way or another because enough people would have wanted to run Windows programs on Linux in a world where Linux had dominant market share. For Pete's sake, there are Commodore 64 emulators for Linux in a world where that system has been dead for decades. It has nothing to do with what "works" or not. WINE and Proton are developed as actively as they are today because Microslop has been able to market so effectively to convince average joes and businesss leaders to buy their crappy OS. This has nothing to do with the quality of APIs.

> They could have simply invented a better API that didn't suck.

Is there ever a situation where this statement isn't true? Everything built in software can be seen as sucking, and all software could have been written better the first time around.

[lenkite]

> It's Linux's failure that one of the world's biggest corporations outspent it on marketing by orders of magnitude?

No, It is Linux's severe failure that it lacked a singular, stable, and unified userspace GUI API.

[adithyassekhar]

> No, It is Linux's severe failure that it lacked a singular, stable, and unified userspace GUI API.

Careful, some people are too hell bend on idealogies than making a reliable product. They'd never understand this.

This is one of the reasons why open source (free as in beer) will never work for anything serious. When my work depends upon a software someone made for free, there's an unnecessary power dynamic in play where since I didn't pay for it, they can rugpull me anytime. Before someone comes with the argument of forking, that's not how an economy works. I can't be the farmer, the truck driver, the salesman and sometimes even the buyer at the same time.

The kernel doesn't owe anything to the distros, which is insane, distros doesn't owe anything to the various libraries and vice versa, none of them owes anything to the application developers. It's a boat where each person is rowing in their own direction because they don't care what others does with their code and they don't have to. Because they are working for FREE®.

The effects of this is catastrophic. Everytime I try to switch, I can't find a single userspace application that works half as good as windows applications. People need incentives to make their work good, no one does anything for free. Free just means it sucks.

If microsoft/apple/google tomorrow releases their own distro, every single one will abandon their flavor of the week arch/ubuntu/mint/fedora for that one. One that's made by people in exchange for money. I bet the ubuntu developers use macbooks.

[ElectricalUnion]

> When my work depends upon a software someone made for free, there's an unnecessary power dynamic in play where since I didn't pay for it, they can rugpull me anytime.

I would daresay one of the reasons why Win32 is so stable, is because Microsoft itself rugpulls even stuff they offer as "improvements" and "better" (WinForms, WPF, UWP, WinUI 3, MAUI, Blazor Hybrid, WebView2 come to mind), so everyone else can't trust anything but the basics.

AKA: When my work depends upon a software I paid for, they still rugpull me.

[ravenstine]

> Everytime I try to switch, I can't find a single userspace application that works half as good as windows applications.

And if you do find one and update the package, suddenly you find the application has been severely rewritten with the new UI toolkit du jour and the developers dropped a bunch of features they didn't feel like supporting because reasons. Then these same folks act like it's all the fault of Microslop and Fapple that people don't use Linux distros.

[cmeacham98]

> Linux adopted Win32 because it actually worked.

Completely untrue - Linux "adopted" Win32 because the majority of video games are written for Windows (and thus Win32).

They could not have invented a better API because the entire reason Proton exists is because developers don't build native Linux games.

[forrestthewoods]

> because developers don't build native Linux games.

Correct. However you grossly misunderstand why why dev don't build native Linux games. The answer is that distributing proprietary software that works on "Linux" is an absolute unmitigated clusterfuck of pain, misery, and woe.

Cross-platfrom is very very easy. It's a solved problem. There are indie devs with custom engines that can easily ship for Windows, macOS, iPhone, Android, Playstation, Switch, and Xbox.

If Linux userspace had an ABI that wasn't garbage then adding "Linux" to that list would be very easy. The fact that devs don't and it is your primary clue.

I keep putting "Linux" in quotes because back in the day with r/LinuxGaming would spam Kickstarters begging for Linux support that's what they asked for. Of course there is no such thing as shipping for Linux. There is the Linux kernel and glibc and a kajillion different distros that are all unique and terrible in an myriad of different ways.

And it turns out that Linux is such a minefield clusterfuck that the actually best ABI is Win32. It'd be great if Linux designed a new ABI that was better. Seriously, that'd be awesome. But in the meantime Win32 it is!

[MathMonkeyMan]

> It is a hilarious and catastrophic failure of Linux userspace that the best API for running games on Linux is Win32

Studios don't target Linux, they target Windows and sometimes Mac.

Imagine if Flappy Bird targeted only iPhone, because there were only 50,000,000 Android users in the world (hardly worth supporting). Then Android creates an iPhone runtime on Android so people can play Flappy Bird on it, and you conclude "iPhone actually worked, this is evidence that Android is a hilarious and catastrophic failure."

[forrestthewoods]

I don't need to imagine a made-up scenario that doesn't make sense. We can look at what has happened at face value.

The calculus is very very very boring and simple. Game devs will support every single platform on the planet in which the cost to support that platform - both directly and long-term maintenance - is less than the increased revenue that platform provides.

It is not uncommon for indie games on custom engines to support Windows, Playstation, Switch, Switch 2, Xbox. And, depending on the game, iOS or Android. Sometimes macOS although that's increasingly rare.

Native Linux builds are pretty rare. Especially before Proton got pretty good with Steamdeck release.

Supporting Linux is a monumentally tremendous pain in the ass. Radically more than literally any other platform. It is hands-down the hardest and most painful to support natively. So painful that emulating Win32 is a clear win. Valve's runtime helps a lot. And supporting another path is just a waste of time.

Very sad!

[Epa095]

> The calculus is very very very boring and simple. Game devs will support every single platform on the planet in which the cost to support that platform - both directly and long-term maintenance - is less than the increased revenue that platform provides.

Companies end up not doing profitable things all the time, for many reasons. One rational reason is that while action 1 might be profitable, action 2 is even more profitable. So the fact that Linux is not supported does not show that it would not be profitable, but rather that there are other things the companies can use labour for which they think is even more profitable. If they could freely clone their employees (and "unclone" them afterwards) all profitable things would get done.

(This is just nitpicking about your economic argument, I have no reason to think your conclusion is wrong).

[forrestthewoods]

You are correct. You're talking about "opportunity cost"

I kinda touched on it with "and long-term maintenance". For video game ports you can bypass the direct opportunity cost by doing a rev-share deal with one of a million port houses. They'll do 100% of the work to port to a new platform, and then you split revenue. It's not totally free because of course there's overhead. And if you want to do patches, DLC, sequels, etc etc there's the maintenance cost.

Which is to say yes you're basically correct and I agree with you.

[arcfour]

> Supporting Linux is a monumentally tremendous pain in the ass. Radically more than literally any other platform. It is hands-down the hardest and most painful to support natively.

Funny, I have the same feelings after 5 seconds of using MSVC or looking at Win32 documentation. Or is it WinRT now, or is it .NET Core, or .NET Framework, or UWP or OLE or COM, or whatever the API du jour is which will be slightly incompatible and incomplete with the rest of the ecosystem in poorly documented and inscrutable ways?

Performance profiling and debugging tools are critical for game development. What's your equivalent to strace again, the one that's built into the system natively? There isn't one?

All major game engines I am aware of support native Linux builds and have for years, anyways.

I guess there's a reason 80% of the servers in the world run Windows. Because it's so hard to develop for. Er, uh...no wait!

[forrestthewoods]

Sarcasm is an extremely poor method of communication. Speak plainly and clearly.

> Performance profiling and debugging tools are critical for game development.

Profiling and debugging tools are RADICALLY superior on Windows. RADICALLY. GDB/LLDB is garbage. For debugging Visual Studio (for adults, not VSCode), or on special occassion WinDbg, is great. Raddbg may be awesome some day and may also support Linux. That'll be great. Today is not that day.

Superluminal is spectacular. They're working very hard on a Linux version. It's taking them a long time because Linux is bad.

> All major game engines I am aware of support native Linux builds and have for years, anyways.

Unity and Unreal do have buttons to export to Linux. Most proprietary game engines don't have Linux clients. Linux for headless servers you control is fine.

> 80% of the servers

Yawn.

The Linux pain is trying to deploy proprietary binaries that run on customer machines which are infinite in variation. Running headless on a single Linux image you control is very different.

Anyhow. Let me know when you ship a game with 3D graphics to customers and have to deal with all their support issues!

[arcfour]

Hey, want to race to install toolchains? I'll install everything I need to build the Linux kernel and, say, typical SDL2 applications. I'll give you a 3 hour head start, all you have to do is install Visual Studio, WDK, and the Windows SDK, and hope they play nicely with each other!

Good luck! Then we can switch places so you can install for the 5.3% (and growing) of your gaming userbase that doesn't use an OS with ads in it.

P.S. he who lives in the house of WinDbg is not allowed to throw stones. At anyone. Ever. Nobody thinks that it is "great," you must be kidding.

[fyredge]

I think you are coming at this with very different priorities. For most people, installing tool chains is a one time job, that they can grit their teeth through if it works well for them. No one wants to constantly install or reinstall and make sure the installation process is lightning fast.

It's the reason why Linux still hasn't taken off on desktop. People want good application support, not infinite customisations and blazing fast compile speeds. In fact, slow compile speeds might even give people an excuse to go chat with colleagues and take breaks. What you want is not what others want too

[forrestthewoods]

It's funny you mention that.

You know which platform is super duper mega easy to cross-compile to? And you know what platfrom is (almost) FUCKING IMPOSSIBLE to compile against an arbitrarily old version of glibc? The answer (in order) is Windows and Linux.

But in anycase you still have it wrong. Compiling and running for your machine isn't the problem. The question is can you give me a binary that runs on my machine. And also I'm not going to tell you what the environment is. But I will yell at you if it doesn't work.

Anyhow. Portable toolchain install for MSVC + WinSDK took about 30 seconds to download. Very easy. Here you go: https://gist.githubusercontent.com/mmozeiko/7f3162ec2988e81e...

I do agree it's annoying this isn't default behavior.

> you must be kidding.

Geez you are very frustrating to communicate with. I literally said "for special occasion". Good grief. Visual Studio debugger is kinda mediocre but still best-in-class and Linux doesn't even have an equivalent to compare against. WinDbg has some slick commands for super niche cases. Awful GUI with no discoverability though. (Just like Linux! bad dum tsh)

[delta_p_delta_x]

> Hey, want to race to install toolchains?

Not the parent commenter. It's really not that hard.

MSVC: https://visualstudio.microsoft.com/downloads/?q=build+tools#...

Clang targeting MSVC ABI: https://github.com/llvm/llvm-project/releases/download/llvmo...

Clang targeting MinGW ABI: https://github.com/mstorsjo/llvm-mingw/releases/tag/20260421

GCC targeting MinGW ABI, running in MSYS2: https://github.com/msys2/msys2-installer/releases/download/2...

Or, if you want a command-line, winget makes it easier still:

  winget install -e --id Microsoft.VisualStudio.BuildTools LLVM.LLVM MartinStorsjo.LLVM-MinGW.UCRT BrechtSanders.WinLibs.MCF.UCRT

One-liner, roughly on par with `pacman -S base-devel clang llvm`. To install libraries, I use `vcpkg add port sdl2` in my project, a la cargo. No more fudging with system-level dependencies.

[winrid]

the other way around is kind of how libgdx games run on iOS :)