[pjmlp]

I feel relying on WINE and Proton instead of building a proper GNU/Linux ecosystem will eventually backfire, it didn't happen already because thus far Microsoft chosen to ignore it.

However as Steam vs XBox slowly escalates, Microsoft might eventually change their stance on the matter, forcing devs to rely on APIs not easier to copy, free licenses for handhelds, taking all Microsoft owned studios out of Steam, see which company has bigger budget to spend on lawyers, whatever.

[baq]

WINE and Proton piggyback on Microsoft's guarantees of Win32 stability. As long as that remains in place (which should be for all intents and purposes forever given MS's customers) they can't really do anything about it.

So, next time you hear the joke about Win32 ABI being the only stable ABI on Linux, remember it's funny because it's true!

[Dalewyn]

Don't forget Windows finally made Year of the Linux Desktop(tm) a reality, Windows is the best desktop Linux distro (Android gets the mobile Linux distro crown).

[pxc]

Windows' desktop environment is much too lackluster for that. It's uniquely inconsistent (many distinct toolkits with irreconcilable look-and-feel, even in the base system), has poorly organized system configuration apps that are not very capable, takes a long time to start up so that the desktop becomes usable, is full of nasty dark patterns, suffers an infestation of ads in many versions.

Besides the many issues with the desktop itself, Windows offers piss poor filesystem performance for common developer tools, plus leaves users to contend with the complexity of a split world thanks to the (very slow) 9pfs shares used to present host filesystems to guest and vice-versa.

And then there's the many nasty and long-lived bugs, from showstopping memory leaks to data loss on the virtual disks of the guests to broken cursor tracking for GUI apps in WSLg...

[SoothingSorbet]

> It's uniquely inconsistent (many distinct toolkits with irreconcilable look-and-feel, even in the base system)

While I agree that Windows has long since abandoned UI/UX consistency, it's not like that is unique: On desktop Linux I regularly have mixed Qt/KDE, GTK2, GTK3+/libadwaita and Electron (with every JS GUI framework being a different UI/UX experience) GUIs and dialogs. I'm sure libcosmic/iced and others will be added eventually too.

[pxc]

> On desktop Linux I regularly have mixed Qt/KDE, GTK2, GTK3+/libadwaita and Electron (with every JS GUI framework being a different UI/UX experience) GUIs and dialogs.

And you can choose to install GTK+, Qt, and Electron apps on Windows or macOS, too. That has no bearing on the consistency of the desktop environment itself (not on Linux or on macOSa or on Windows). That fact is simply not relevant here.

You could point to some specific distros which choose to bundle/preinstall incongruous software— those are operating systems that ship applications based on multiple, inconsistent UI toolkits. But that's neither universal to desktop Linux operating systems nor inherent in them. Many cases that do serve as examples by the definition above are still not comparable to the state of affairs on Windows— for instance, KDE distros that ship a well-integrated Firefox as their browser— are on the whole much more uniform than the Windows UI mess.

[wqaatwt]

> could point to some specific distros which choose to bundle

Why does that matter if that’s not how most users do it? There is no magical dividing lines between a distribution and the user choosing to install a random collection of apps on their own.

[wqaatwt]

> has poorly organized system configuration app

To be fair almost all Linux distros are as bad if not worse in this regard.

Things like YAST which are supposed to fix that are unambiguously horrible in their own right (extremely slow, crappy UX etc)

[pjmlp]

If all one wants it to run games that use the Win32 API as defined today, surely.

If all one wants it to run games that use the Win32 API as defined tomrrow, anyone's guess.

[int_19h]

If the API only has additions, then Microsoft would still need to convince game devs to actually use them (and Valve will point out that if they do, their game will not work on Steam Deck, so there's a clear downside).

If some APIs are removed, it breaks older Windows games. I can't think of any historical API that has been completely removed in this way - even stuff like DirectDraw and DirectPlay is still there even though it has been deprecated for decades.

[pjmlp]

See ABK deal, Microsoft has tolerated SteamDeck thus far, they own the platform.

[wqaatwt]

What about it? I’m just curious what specifically do you think MS could do that wouldn’t get them into extreme trouble with the EU/FTC?

[robertlagrant]

They could create a new interface that's somehow more efficient, and work with Unreal / Unity / Godot and a few others so it's just a recompile for them, but it's a bigger problem for Wine, perhaps? I'm just thinking out loud.

[baq]

Note this is a huge improvement from 'binary is guaranteed to not work in the future, probably not too distant' of the standard model of Linux distributions.

[wqaatwt]

If Linux gaming picks up and it gains significant market share then that is not an issue. Game developers will not use APIs that don’t work on the machines of ~20% of their users (or won’t make it mandatory, anyway)

Considering the alternative (ie. the native approach) would result in having very few games on Linux anyway that doesn’t seem that bad.

[InsideOutSanta]

There's a good chance that if that if Microsoft doesn't act soon enough, and a lot more devices running Steam OS are released, Proton might become the de-facto platform against which many new games are developed, and which engines target.

At that point, there is nothing Microsoft can do.

[freedomben]

Agreed. I actually think it might be too late at this point since it takes so long to turn the aircraft carrier.

Microsoft can't realistically deprecate/remove Win32, so all they could do is entice with new APIs. That will work for some games, but especially with the frameworks in place, they'll have to be really good to get people to abandon Steam Deck compatibility to use them.

[pjmlp]

They already control enough studios, PC and XBox market.

SteckDeck compatibility relies on "emulating" Windows ecosystem.

Remember DR-DOS, OS/2 and EEE PC.

[BlueTemplar]

EEE PC was tiny, IBM (OS/2) were full of hubris, what happened to DR-DOS ?

Valve is neither tiny, nor does seem to be under the thrall of hubris. Also Microsoft seems complacent so far, though that might change.

[pjmlp]

Originally Windows was designed to detect and not run if using DR-DOS.

[wqaatwt]

Sure, MS could purposefully try and make their first party games not run on Linux.

However.. why? It would be the same as purposefully losing money but not selling on Steam.

Besides that what could they do? Within getting into all types of legal trouble?

[kbolino]

They bought a lot of companies and are doing their level best at running them into the ground. Xbox is a dying platform. They may try some things that they've tried before (GFWL) but they're not going to succeed this time either.

Kernel-level anti-cheat is a bigger threat to gaming on Linux than anything Microsoft has directly done, but even that is fixable.

[robertlagrant]

> Kernel-level anti-cheat is a bigger threat to gaming on Linux than anything Microsoft has directly done, but even that is fixable.

Agreed. Valve providing some service that gives local games less info, so they literally don't know where players are until they need to, might spell an end to wall hacking at least.

[cyberax]

> Kernel-level anti-cheat is a bigger threat to gaming on Linux than anything Microsoft has directly done, but even that is fixable.

I can see companies sending out hardened Linux distros to hardcore Valorant players for official tournaments and such.

[pjmlp]

Microsoft controls Windows and DirectX, Valve only gets to play until Windows landlord allows it.

DR-DOS, OS/2 and EEE PC.

Lets see if SteamOS makes the list as well, this is after all round two, Steam Machines didn't go that well.

[jwcooper]

The Steam Deck is basically the successor to the Steam Machines. The actual hardware didn't go that well, but they laid the foundation in software for what we have now.

So, in a way, the Steam Machines were a great success.

Also, Valve has (for better and worse) far more power and control in the gaming ecosystem than most companies Microsoft has to deal with.

[pjmlp]

Depends on how many key AAA studios are part of Microsoft Game Studios portfolio.

[Yeul]

Microsoft tried to put their games on their own store but they crawled back to Steam.

Honestly Windows is more open than MS haters give it credit for.

[pjmlp]

They did, does mean they will let Valve screw SteamOS on their face.

[wqaatwt]

And what exactly would they do?

[kbolino]

Yeah, GFWL was a debacle that has thankfully been largely forgotten. If Microsoft couldn't pull it off back then, they're not going to today.

[BlueTemplar]

They now own Activision-Blizzard-King, which even now (new Battle.net) is still better than GFWD ever was.

[cyberax]

> Microsoft controls Windows and DirectX, Valve only gets to play until Windows landlord allows it.

DirectX has to stay reasonably close to Vulkan. And Vulkan is not an afterthought for graphics card manufacturers, quite unlike OpenGL of yore.

And Win32 (sans Vulkan/DX) is mostly feature-complete for gaming purposes. Manufacturers can just target the current state of Win32 for a decade more, if not even longer.

[pjmlp]

It certainly is, in what concerns NVidia, they keep innovating first with Microsoft on DirectX, and then eventually come up with Vulkan extensions.

Last example, AI shaders announced at CEBIT.

Vulkan has turned into the same extension spaghetti as OpenGL.

[cyberax]

> It certainly is, in what concerns NVidia, they keep innovating first with Microsoft on DirectX, and then eventually come up with Vulkan extensions.

I don't get that impression. I can't remember the last significant feature that was present in DX first, and not immediately or shortly available in Vulkan.

[wqaatwt]

So any more “native” alternative to Proton would do even worse because at least not it’s at least keep Linux in sync with the real world?

[jandrese]

On the other hand building Linux binaries and keeping them running for years without maintenance has proven far more difficult than emulating Windows.

For an example track down the ports Loki games did many years ago and try to get them running on a modern machine. The most reliable way for me has been to install a very old version of Linux (Redhat 8, note: Not RHEL 8) on a VM and run them in there.

[pjmlp]

Naturally it means GNU/Linux will never improve until being forced upon.

[jandrese]

It just means Microsoft has put more emphasis on ABI compatibility. This makes sense. In the open source world ABI compatibility is less of an issue because you can just recompile if there are breaking changes. ABI compatibility is far more important in a commercial closed source context where the source may be lost forever when a company shuts down or discontinues a product line.

[BlueTemplar]

It would be really nice to see open source being more widespread in games, though of course it's harder because they are more art than software.

Splitting code and audiovisual assets might work ?

[jandrese]

Even then the rights get dicey when they include third party libraries and development systems. Doom famously had issues with the sound library they used.

Plus, with commercial software it often happens that the code only builds cleanly on one specific ancient version of a closed source compiler in a specifically tweaked build environment that has been lost to the ages. Having the source helps a lot, but it is not a panacea.

[BlueTemplar]

Yet both of these issues seem to plague closed source software more than open source ?

Doom wasn't developed with open source in mind, was it ?

What open source software "only builds cleanly on one specific ancient version of a closed source compiler in a specifically tweaked build environment that has been lost to the ages" ?

[wqaatwt]

It didn’t for decades (in this specific regard) why does you think it could change?

People running Linux hate software shipped as binaries due to various technical and ideological reasons. Why would this change?

[mschuster91]

> I feel relying on WINE and Proton instead of building a proper GNU/Linux ecosystem will eventually backfire, it didn't happen already because thus far Microsoft chosen to ignore it.

Microsoft can't do shit against WINE/Proton legally, as long as either project steers clear of misappropriated source code and some forms of reverse engineering (Europe's regulations are much more relaxed than in the US).

The problem at the core is that Linux (or to be more accurately, the ecosystem around it) lacks a stable set of APIs, or even commonly agreed-upon standards in the first place, as every distribution has "their" way of doing things and only the kernel has an explicit "we don't break userspace" commitment. I distinctly remember a glibc upgrade that went wrong about a decade and a half ago where I had to spend a whole night getting my server even back to usable (thank God I had eventually managed to coerce the system into downloading a statically compiled busybox...).

[pjmlp]

They surely can, and Valve got lucky UWP didn't took off as they feared.

Microsoft can easily do another go at it.

That is the problem building castles on other vendor platforms.

As reminder,

https://www.extremetech.com/gaming/127475-valve-confirms-ste...

[jwcooper]

Microsoft is going the opposite of what you're suggesting. Their games are coming to Steam, Playstation and Switch. Also, their game division isn't exactly thriving right now. They have a ton of studios, but they are not selling hardware very well right now.

The more that time goes on, and the more entrenched steamOS/Proton becomes, they will not have any sort of easy time trying to lock-in to Windows. Even now in the earliest days of steamOS, there is blow-back when a game does not support the Steam Deck (which means Proton).

[pjmlp]

Playstation and Switch, for sure.

Steam, not on detriment of Windows, how can they allow something like SteamOS to put Windows to shame, with their own APIs?

I can bet on them changing that, lets see who's got deeper pockets.

[dehugger]

I would posit that in this scenario it is Valve who has the deeper pockets. It's a privately owned company and not beholden to the whims of a quarterly driven revenue cycle, and it's a matter of life or death for the organization.

In contrast, gaming is essentially a side show for Microsoft. The resources required to push Valve off it's pedestal would have higher returns invested elsewhere.

[brirec]

Most of their biggest games already are on Steam, though!

[lukevp]

Games aren’t going to suddenly start targeting only updated copies of windows 11 though… if they target even win 10 then they need to be API compatible with what’s currently there in windows. It doesn’t matter what new stuff comes out. Just like how we had to keep using ie6 compatible code for ages for the 5% of people still on windows xp even though it kept us from using modern web tech for everyone else.

[pjmlp]

Depends on how much Microsoft decides Windows Store and XBox App are relevant for game developers targeting the PC going forward.

[PittleyDunkin]

They can't stop publishers from targeting steam/proton, though. The publishers will go to where the market is. Sure maybe they can restrict the version published to whatever store windows has but they can't prevent the one distributed with steam targeting an older version.

[pjmlp]

They can on the studios they own, and publish.

[frankchn]

Right now, they are not even making their own games exclusive to Windows Store or the XBox App (see MSFS 2024, Age of Empires series, Forza, etc...).

[pjmlp]

Because until recently SteamDeck was a non issue for Microsoft.

If it starts being a big issue, they won't ignore it.

[mschuster91]

> They surely can, and Valve got lucky UWP didn't took off as they feared.

So what, assuming it had taken off it would just be yet another set of crap APIs to develop wrappers for.

[pjmlp]

So is the burden of playing with other people toys.

[wqaatwt]

Still a nicer problem to have than developing “non crappy” APIs that nobody uses or cares about.

[wqaatwt]

> forcing devs to rely on APIs not easier to copy

Would that still not be easier than developing something stable and finding ways to force 3rd party developers to support Linux? (when you can offer them anything in return)