And Windows 10 can emulate the Super Nintendo. But multiple consoles are not as cheap as the Windows box you already have, more annoying to setup or stow, and don't have some little QoL addons, like freezing the game.
What you're emulating is irrelevant. What matters is which provides a better experience to you, the end user. One choice is actively being worked on, while the other (despite under-the-hood perf. improvements IIRC) seems to garner more loathing and disdain with each release.
Linux folks swearing for "Linux games" that are in reality Windows games running on top of a Windows emulation layer are the ones missing the forest from the trees.
Proton is just a new desktop application API for Linux, one specialized for gaming. While the win32 API is certainly not an open standard, it is a stable one, arguably more stable than even browser APIs, and obviously more stable than the various APIs offered by Linux.
Years ago I was optimistic that fixed shared library runtimes, such as the ones offered by Steam, would be enough to make native game development for Linux viable. But even with these, so many things simply break in places they should NEVER break, and can only be fixed by recompiling them (thanks glibc), so I no longer feel this way.
While my heart bleeds for open source, video games are fundamentally more art than function, so the expectation that the user (or the upstream maintainer, Steam) needs to be capable of recompiling them is simply unrealistic when considering the licensing & support required for this. Video games need a stable API, perhaps even more than most other types of software. A game built 10 years ago should continue to work when run today.
When considering all of this, along with the fact that Valve is the only large organization with the resources and incentive to fix this situation. The only real path forward Valve has here is to create their own custom desktop application API for Linux that goes beyond just a set of shared libraries and is fully integrated, meaning third-party game developers don't need get involved in the often messy inter-library politics the Linux community is accustomed too.
But if Valve really needs to go that far, why invent a whole new API for it? Why not just copy win32? That's the most popular API among game developers after all. In fact there is already a Linux runtime that not only supports win32, but actually treats desktop stability as a core priority: WINE. Why not just throw resources at that instead of making something new?
While I'm mostly speculating here, I suspect that this line of reasoning is what gave birth to Proton. It has also led to interesting situations, consider this: Elden Ring on release had/has a problem with micro-stuttering, this issue was patched in Proton very quickly, within the first week of release, but remains an issue on Windows to this day. This means that right now, Linux is the best platform to play Elden Ring on if you want the best performance and graphics. Much like video drivers are updated to fix bugs for individual games, Proton now fills this role as well, but with an even faster development cycle.
This highlights one of the key benefits of Proton: it scopes an entire Win32 runtime (wineprefix) to each game. A hasty hotfix for one game will not break another, each game needs to only pin the runtime that works, and no further tweaking is necessary. You simply cannot do this on Windows, Microsoft does not have this kind of flexibility.
A future where Proton outlives Windows, one where Proton expands the win32 API to include more features never supported by Windows, while I can't say it will happen, it certainly can happen, and I'm excited to see where this goes.
One thing that gets me with proton is that as you say it effectively 'crowns' win32 as the PC gaming platform, but it seems like a weird situation where MS control it and valve/codeweavers are constantly chasing them for any new/changed functionality so their sub-platform remains relevant. I think an opportunity has passed to divorce PC gaming (or perhaps "consumer real time 3D"?) from MS/windows because Valve don't want to take on all that responsibility, and no one else is interested enough to set up a consortium to pick up that gauntlet.
This is my cynical side, but I'm sure they don't mind the opportunity to get their store in front of people, both with the deck and by how closely knit steam is to providing gaming to non-windows PCs. In my view PC gaming is in a weird spot right now if you try defining "what is the platform?" Is it windows, is it steam (and all the other features it has), is it x86, how much can/should a game be 'portable' from one ecosystem or enclave of PC. There's also been issues with games like Starfield not working with the intel Arc GPUs until a few days ago that have me wondering (from a fairly naive point of view) how closely that aspect is tied to assuming nvidia/AMD are the only possibilities versus how well it was written to the abstraction layer, assuming intel were compliant.
If enough players play via Proton and want to stay that way, then the subset of the Win32 API that is well supported for Proton can itself become the standard. MS might add new APIs, but developers may choose to keep the old ones, therefore targeting the largest userbase.
Of course, MS might also start changing the behaviour of lots of APIs, deprecating them left and right, effectively trying to kill Proton. But that means they'll also kill their own backwards compatibility.
If, again, Proton becomes "popular enough", I don't see how MS can stop it short of finding some way of preventing developers from using old APIs in new applications (which would very likely be anti-competitive behaviour).
I've been a macOS user for 11 years now, but I hope that, however unlikely, Proton wins out :)
Isn't this the whole reason Valve created steam runtimes so that they could have native linux binaries with also long patch lifetimes? AFAIK they even select Ubuntu LTS releases so they can surf off upstream patching for longer.
Ubuntu's extended support even pushes that out to 10 years, and I imagine Valve could also do its own patching (or just ignore security concerns).
Nice thing w/ Valve is they allow you to use your distro's libraries or switch to the runtime, depending on how much performance you are trying to eke out of a game.
Odds are anything written a decade ago doesn't need cutting edge performance though.
I briefly touched on this but steam runtimes (aka shared library runtimes) in practice aren't as isolated as one would assume, an update to glibc is often enough to break applications targeting them. Furthermore, in practice many maintainers think little of video games and are often comfortable breaking them if it helps with the server side of things.
For evidence of this, look no further than Ubuntu, the basis of the steam runtime, dropping 32bit support and breaking all software (video games) that depend on it. Sure you can still use it for older stuff, but there is no future here.
Well. Microsoft is also dropping 32 bit support for Windows 10 in 2025. I guess that makes Proton some weird hackish abstraction layer over the continuously updated underlying linux libs.
Would be funny if Proton gets pulled into Windows releases to maintain support for legacy games as Microsoft shortens the length of their support.
Ah yeah, you're right. WOW64 appears to not be going anywhere anytime soon.
Although. I gotta say, I don't use windows much, but some folks I kind of helped out on the side were upgrading to Windows 8 and were completely unable to launch their 32 bit XP accounting software binary with every emulation flag I tried. (could just have been my inexperience on this, but wasn't finding anything in the support guides).
Oddly enough, it ran fine in Wine in virtualbox in a small ubuntu instance, so they ended up just using that in seamless mode.
So, at least from past experience that legacy compat is not 100% and I'm guessing games might be even more finicky than accounting software.
They are however (by dropping the 32bit versions of Windows) dropping 16bit support. Which still exists in 32bit Windows 10 along with NTVDM (AKA DOS emulation). So I guess it's the end of the line for MSDOS?
>But if Valve really needs to go that far, why invent a whole new API for it? Why not just copy win32?
I can think of at least two reasons:
Legal - APIs might be copyrightable in the future.
Control over changes - Not having to play ketchup every time Microsoft changes or updates an API. Windows APIs do still change and break applications they have compensated for this with application specific shims.
That being said I can't imagine what Valve would come up with. Maybe they could base something around Vulkan, Musl and Wayland.
Yes. But that's the thing - if more and more people play games on Linux (even through Wine), there will be more Linux machines around.
Developers might be more interested in developing for it if it is more than a footnote of an OS, possibly creating a positive feedback loop. Especially with companies such as Valve invested into it.
To those who might not be aware: Wine originally stood for "Wine is not an emulator", a recursive acronym that were popular in the geek culture a few decades ago. Same for KDE Desktop Environment and GNU's not Unix.
I guess this falls under "other features" but it's pretty common to emulate systems behavior via a re-implementation, or thunking calls to a copy of the original libraries, etc.
Oracle uses the verb "emulate" to describe branded zones, which function similarly, as well. I think it's semantically fine to call this emulation, it's just high-level emulation.
If Linux offer a layer of compatibility with Windows API, abd devs release games ensuring that the games run on that compatibility layer, the distinction of "but they don't release games natively for Linux" is largely irrelevant.
Linux is a better OS than Windows in mostly every way, and what held a lot of people from making the switch was the inability to run their game library there.
Nowadays, I can run the vast majority of my game library on Linux without any issues. In fact, older games are often better supported by WINE/Proton than by Windows itself. And the situation seems to only improve as time passes.
