>that Wine/Proton helps make the Win32 and DirectX APIs a sort of de-facto cross-platform standard when it comes to things like desktop gaming, and that this is a good thing for them.

I'm not sure if it benefits microsoft in the long term, because the "backwards compatibility" features of Wine need to be implemented in Windows already as a part of the system. So in the long run wine/proton/mono will implement windows features on linux in an optional/replaceable/modular way in user-space while keeping backwards compatibility for older windows software, while windows is forced to implement (and distribute these features) with their OS and has to sacrifice backwards compatibility if they want to simply their OS.

I would say that the adoption of wine/proton helps the linux ecosystem a lot more because there wasn't a standard executable format for linux beforehand (static? tarball of program and dynamic libraries? .deb file? AppImage? Flatpak? Higher-level language like java?). How do you reliably link to libraries like mesa or even glibc? Now there is a solution: just distribute a windows program and test it to confirm it works in wine/proton. Perhaps it is better for DirectX adoption, but it seems like Vulkan/OpenGL/WebGPU are still superior in terms of cross-compatibility, regardless if you use wine or not.

> there wasn't a standard executable format for linux beforehand (static? tarball of program and dynamic libraries? .deb file? AppImage? Flatpak? Higher-level language like java?).

By this logic there wasn't a standard executable format for Windows, either (static? zip archive of program and dynamic libraries? .msi file? installer program? UWP? higher-level language like C#?).

Windows NT (2000, XP, etc) used to include an emulator allowing to run DOS apps and win16 apps. I don't see why running older / obsoleted win32 APIs through an emulation layer won't be a good approach. Maybe even by adopting and running Wine.

> I'm not sure if it benefits microsoft in the long term, because the "backwards compatibility" features of Wine need to be implemented in Windows already as a part of the system.

Sometimes running old software atop Wine on Windows is the easiest - or even only - option to have said old software work on new Windows.

I disagree. MS was completely succesfull in their goals. They kept a ton of developers busy learing useless Xamarin, thus keeping them from developing products that can actually compete with Microsoft products.

Next they killed of an open source competitor (Mono) of their product, stole the usefull bits to put it in .Net, and now they dump the leftover project (that's not competing with them anymore) back into the OS world.

How is that not a smart way of doing business?

> stole the usefull bits to put it in .Net

a nitpick, they acquired Xamarin for half a billion dollars, that's not really stealing is it.

I don't think Microsoft viewed Mono as a competitor. Even before Microsoft acquired Xamarin for hundreds of millions of dollars, they already had a history of collaboration on .NET, including sharing test cases in order to help with compatibility, and co-developing integrations into Microsoft products such as Azure and Office 365.

The "keeping [developers] from developing products that can actually compete" assertion is frankly absurd. .NET's real competitor is and has always been Java. Java, possibly the world's most-used platform that isn't JavaScript, has always had heaps more people working on it than .NET's entire ecosystem, let alone just the Mono project.

> kept a ton of developers busy learing useless Xamarin...

What kind of moustache-twirly stupidity is this? Yeah, Microsoft maintained a shitty cross-platform SDK so that developers would make worse software, because that's somehow helping any of their main product verticals. By the way, those are (broadly speaking) cloud, client software, and games.

Do you have any evidence to suggest that there was a Xamarin-based application that would have directly competed with Office? How about Fallout? Now, do you have any evidence that Microsoft tried to make Xamarin worse at doing the thing that application was trying to do?

> Next they killed of an open source competitor (Mono) of their product

Microsoft's implementation is also open source, and has been for almost a decade: https://github.com/dotnet/runtime

> that's not competing with them anymore

Sure. Mono is only useful for legacy purposes. Microsoft's own design was always the reference implementation of .NET, regardless of whether it was open-source. Mono existed for the sole purpose of being an open, cross-platform reimplementation. Now that the reference design is itself open-source and cross-platform, Mono is mostly redundant.

Microsoft as a company is extremely myopic. Budgets are scrutinized down to the penny every few months at very senior levels. This drives a culture of immediacy. Wine was a threat until Microsoft realized everyone in tech had moved to service based business models (aka "cloud"). Only afterwards, did they "realize" Linux as a threat to their long term viability no longer mattered.

They finally started to admit where they're losers and stop trying to fight those battles.

Dumping endless piles of cash into projects nobody cares about and pretending like you're the dominant player when you control some dwindling 2% of the market is stupid and more companies should learn that lesson

I think it's more because individual pc instances literally doesn't matter anymore. Operating systems and programming languages which lock you into them are irrelevant from a revenue standpoint.

And that's why they have a $3.08 trillion market cap

The aircraft carrier will hit the shallows, but that massive inertia can "carry" it for decades without any new thrust.

Remember when Microsoft was able to fight off the Web with piss-poor Internet Explorer? Until it didn't.

I think it's just such a clear business-razor because of the cloud: can I take my app and spin up a bajillion cheapo servers with no licensing costs using that stack?

If the answer for .Net was 'no' then there are meaningful domains where people would just jump ship in a second. Research, academia, teaching, and certain government areas pop to mind. Keeping Linux support, because of that server dominance, is a core concern for them.

Presumably being able to make money spinning up cheapo servers, via Azure, just reinforces that decision.

> I still don't trust MS's motives in general

I think it's the same for any global enterprise: profit.

In that regard, "trusting" something like MS is like evaluating their stock: what do they make money off, what is a threat to that. Which makes it rather easy to "trust" them: if they can make money off SomeOpenSourceProject they'll help it along, if it doesn't help, nor threat, they'll ignore it. If it's a threat, they'll put (some) money towards fighting it.

For me the difficult part, and why I still don't fully trust MS, even with Github or VScode lies in their internal competition: MS has projects that directly compete eachother. Business-wise it makes no sense to me (and is the primary reason I'll stay away from investing in MSFT). But also their internal competion between profit now and delayed profit. MS has often done things (or not done things) that increase the bottom line this quarter, but harm them over years. In that regard too, MS makes no sense to me Business-wise. I guess having a cash-cow-"monopoly" for decades kinda absolves them of the responsibility to run the entire company in a way that makes sense business-wise.

anthropomorphizing complex social institutions such as corporations is ultimately unproductive and a net negative for clear thinking

> Wine/Proton helps make the Win32 and DirectX APIs a sort of de-facto cross-platform standar

There are perfectly fine _actual_ cross-platform standards like Vulcan and OpenGL. If your goal is cross-platform, making a Windows app that you hope will be converted well enough is a strange way to approach it.

And yet, the win32 is the only one that is confirmed to work. Example: Game Neo Scavenger is available for linux with binaries for them. They dont work in any modern linux because (I believe) they were compiled for a 32bits version of linux.

Do you know how you can play the game on linux? Yes, using the windows version with lutris, which is 32bits too.

That doesn't help, most Linux distributions do not maintain ABI (library-program linkage) compatibility between major releases, and in the case of rolling distros half the system has to be recompiled when things such as libcurl, openssl, libc etc change. If these change, it's possible that anything compiled agaisnt the system version of it will no longer work without being recompiled

Windows goes back and beyond for compatibility with existing compiled software and Wine inherits that, is partially why Windows versions under Wine often have a higher chance of running than the native versions (ARK is a great example)

Projects like Flatpak attempt to solve this by the use of runtimes.

And yet, Linux gaming is largely dxvk and proton.

Game studios get a lot more mileage out of testing their games on Linux+Wine than bothering to build a Linux native version that will stop working within two years.

Steam has incentivized this with their Steam Deck Verified program. The Steam Deck being so popular means a lot of studios want their games to be verified on Deck, and if they're verified on Deck then they work in the Linux desktop version of Steam out of the box.

Maybe they feel the same about Wine as I do about WSL.

You can argue that the my-thing-wrapped-inside-your-thing increases exposure to my-thing and that's a net good outweighing any other factors, but you can just as validly argue it helps divert from actual adoption of my-thing and facilitates never moving from your-thing, since no one has any actual empirical study, it's all just feelings and beliefs.

Maybe one logical argument that might have some meat is maybe WSL/Wine just means that the exposure vs crutch aspects cancel each other out (for every user who is exposed to foreign-thing and maybe decides to adopt it, there is another user who thanks to the swallowed version does not ever have to to move), and if that's true, then any imbalance in effects comes down to the the innate virtues of the two things. Both groups of people are equally exposed to both platforms and have equally good-enough use of both platforms, and neither has to actually change to get the benefits of the other, and so the user will choose whichever actually seems to serve their needs the best as their native platform.

I wonder if it's possible to make a desktop backed by WSL that would be a better experience than the current ad/spying-riddled Windows native desktop? Then MS would be forced to try to enshittify WSL so that it doesn't provide an escape and superior experience from the current Windows experience. Is WSL a good thing THEN?

At least for now, WSL has absolute crap access to hardware, not even just like gpus for gaming but even simple things like access to a usb-serial adapter. So, it's probably not possible to make a functional WSL desktop yet. Maybe such things will intentionally never be fixed in WSL just for this reason, so you can only ever use it for pure web app development no different from a cloud instance.