Proton has made enormous strides toward game compatibility through advances in related technologies like DXVK, which enable DirectX 9, 10, and 11 games to run through the Vulkan API. In fact, the project is so far along that Amazon has thrown its hat in the ring, working toward streaming Proton enabled games through Luna. The progress of this effort is updated all the time on ProtonDB, and today they crossed a major milestone as user reports on the site reveal that 80% of the top 100 games on Steam now run on Linux, and by extension, Steam Deck.
I have long stopped even checking ProtonDB to see if the games I’m interested in run well on Linux – I just assume that the games I’m into belong to the 80%, with the remaining 20% being the massive garbage pile that are abandoned indie games, anime nonsense, and porn that have infested Steam over the years.
Proton, and all the work Wine, Valve, and open source developers have poured into it, is arguably one of the biggest contributions to desktop Linux in a long, long time, and with the Steam Deck on the horizon, it’s only going to get even better from here.
“I just assume that the games I’m into belong to the 80%, with the remaining 20% being the massive garbage pile that are abandoned indie games, anime nonsense, and porn that have infested Steam over the years.”
Unfortunately not. According to TFA, of the Top 10 games on Steam, only 4 are Proton compatible. So it’s a pretty good indication that “bad games” are not the only ones that are incompatible, unfortunately.
I’ve also looked for games on steam for the kids only to find that they aren’t supported on linux. Nevertheless I’ve committed to educating them without windows so those non-portable titles may as well not exist(*).
* In which case linux compatibility is 100% – that’s how statistics work, right? 🙂
Have you turned Proton on for all Windows games? Or are you just relying on the ones that have been explicitly ported to Linux. I was amazed at how many “Windows Only” Steam games ran when I turned on Proton Experimental.
tanishaj,
You may be right, although I’m hesitant to buy something if it isn’t marked as supported under linux just to try it. So I filter out windows-only titles from the get-go, but are others finding that unsupported titles work just as well on linux? This is probably easier to test for people who already have a collection of windows only titles in their library.
For me it has been hit or miss. I think it mostly comes down to hardware support in your particular Linux distro. I’ve had the best luck with Ubuntu based distros like Pop!_OS and Elementary, while my preferred “old school” style distros like Slackware and Void require more manual tweaking of the OS itself. I’ve generally had better overall luck with Radeon cards and the open source driver, than with Nvidia and their closed source drivers, but some games that run poorly on Radeon for me (generally Unreal Engine 4 and some Unity games) tend to run better on Nvidia.
Generally, the ones that fail are most likely to be failing due to anti-cheat or other DRMy stuff but, funny enough, I just reported a “doesn’t Just Work™” on regular Wine a few minutes ago.
Turns out the GOG release of Binding of Isaac: Rebirth from a few days ago is completely silent without any error messages to tell you what’s going wrong unless you “export PULSE_LATENCY_MSEC=60” before running Wine.
Anti-cheat and DRMy stuff is the reason I am thinking of jumping ship altogether towards console-land. At least in console-land all that nonsense stays sealed in a purpose-built box. Then I remember I value portability (note: not necessarily mobility, just portability as afforded by a “heavyweight” laptop) and I will probably buy a gaming laptop before I buy a console. After all, you can’t be a tech enthusiast without also being a bit of a masochist in some way or another.
Now with regards to Proton, if they have to provide support for kernel-mode drivers like Denuvo, they might as well close up shop because it can’t happen. Not even Windows can emulate the behaviour of other Windows kernels. This was also a problem in the first days of 64-bit Windows, with people blaming Vista “for breaking Windows XP 32-bit apps” (which it didn’t) while it was actually some copy-protection driver like StarForce not working on 64-bit Vista systems (or even 32-bit Vista systems). I remember DiRT being reported as not working, but I had a cracked copy that didn’t even install the StarForce drivers and which worked fine.
Which brings me to my point: The Proton and Wine people should come clean and make a list of which of the common DRM schemes work and which don’t. And while they are at it, give us an API coverage percentage. In plain English, it’s time for Proton and Wine to stop quoting meaningless statistics and embrace transparency.
Proton? Sure. Codeweavers? Sure… but WineHQ has always left it up to the community to report compatibility at a level beyond what their testbot reports.
(In no small part because any trivial change by a DRM vendor can break things, so having an official report on what should work makes them responsible for failures to work.)
kurkosdr,
I get your point and agree with you completely about the DRM, but I did experience real software breakages with win vista/7 both as an end user and as a developer.
That’s an interesting request. I wouldn’t say “no” to having more data. Do you think there is a strait forward automated way to determine what DRM software is using and also determine that software is broken because of said DRM?
I guess it could be possible to determine the DRM being used by using code fingerprinting similar to antivirus software, but it might be laborious work to get false positives & false negatives down to acceptable limits. Another issue is that unless you are steam you may have to purchase tens of thousands of dollars with of games just to build the database.
Or are you thinking more of a manual user sourced database like ssokolow is talking about? Do end users have a good way to uncover the DRM themselves?
I have never seen Vista (Windows NT 6.x) truly “break a Windows XP 32-bit app”. Any such app I ‘ve seen being broken was because it relied on one of the following:
– 32-bit drivers for some HASP or StarForce thing
– the secdrv driver previously offered by Windows and removed in 10 (you can still have it in 7/8.1 if you enable it), curse you hipsters currently in charge of Windows development
– just boneheaded assumptions about hardware, such as badly-coded timing loops causing frame rate issues on modern computers (Need For Speed 6 is guilty of this for example), or laptop hotkey HIDs/desktop fan Speed controllers being interpreted as gamepads causing the game to crash on start (Need for Speed 5 and 6 is guilty of this for example) or causing frame rate issues (FEAR is an example of this). This also happens on XP 32-bit running on modern hardware so it’s not a Windows NT 6.x compatibility issue.
This is my point btw, you can have a perfect win32 implementation and still have breakages due to drivers and some other things, even if your app isn’t meant to drive any hardware.
The only thing you can do for such DRM drivers is to test all common forms of DRM (there are a handful of companies providing it). Proton should do that for all common DRM that relies on drivers, that’s my point.
And that’s before you get to the point that Proton or Wine are not complete implementations of win32. Some transparency on which functions have being implemented would be great instead of quoting random statistics. After they have done that they can start collecting reports about compatibility, because then any problems are either driver dependencies or programers doing silly things (see above).
The data you ask for is already available if you actually care to obtain it.
For example the unit test results cover WIN32 API functions https://test.winehq.org/data/
But there is also other ways to get to it.
However it appears to be more fun to just shout out requests on the internet. Why should the WINE contributors care about what you want? Are you paying them?
As a matter of fact, most users just need to know “does software XY work or not?”, and they don’t know which API functions a piece of software uses. They also don’t know which API function a piece of software misuses, where Microsoft spends quite a lot of resources to still stay compatible. The best transparency regaring API functions will still not tell you that software XY will work correctly. Which is the reason to use Wine in the first place: Run your favorite piece of software.
@Ford Perfect
Thanks! I didn’t even know the page existed. But how about making sure their own tests pass before calling software others have made “garbage” (their words not mine)?
How is a win32 piece of software that uses win32 APIs correctly but fails to run on wine because wine can’t even pass its own tests “garbage”?
And not to mention the nonsense of tagging an 1.x.x version for a piece of software which isn’t even complete.
BTW if you have examples of XP 32-bit apps broken by Windows NT 6.x that don’t rely on 32-bit drivers or secdrv and were broken on Windows NT 6.x (but not on XP on the same machine) please list them. I am curious.
Also, this doesn’t include Windows 9x apps that performed on XP 32-bit, since these apps often relied on Win16 executables or even DOS executables. I am talking actual XP 32-bit apps.
kurkosdr,
An example is visual intercept, we actually had to keep copies of XP around for customer service until we upgraded the ticketing system. As I recall it would give a runtime error under windows 7 (the company skipped vista).
Yes, so am I.
I just came across a whole bunch of windows updates for application compatibility issues. Unfortunately they don’t give specific details about what was broken, which would have been nice to know, but nevertheless I thought you might find the lists interesting.
Note that I’ve only quoted some of the titles randomly below…
https://support.microsoft.com/en-us/topic/the-windows-vista-application-compatibility-update-90b40511-73b8-4324-4435-97e40f842381
https://support.microsoft.com/en-us/topic/application-compatibility-update-for-windows-xp-professional-x64-edition-windows-server-2003-windows-vista-windows-server-2008-windows-7-windows-embedded-standard-7-and-windows-server-2008-r2-october-2010-6f8e0b53-78d8-9bbb-e18a-335875f38364
And there’s a long list of similar updates. This reminds me that I lost the ability to use video editing software I bought after upgrading from windows xp. I guess it’s entirely possible that many of the applications that were incompatible with windows vista/7 initially could eventually become compatible after one of these updates.
I saw programs fail, but that doesn’t answer whether the OS or program made bad assumptions. So rather than talk about programs, here’s some source level behavior that I saw from Vista which wasn’t compatible and where the program seemed correct and OS seemed wrong:
1. Vista moved “Documents and Settings” folders into “Users” and left “Documents and Settings” links so old programs could open files by their previous path. Unfortunately these links are recursive: there’s a compatibility link that points to its parent. Because anything recursing these would never finish, they are ACL’d to allow named opens but not enumerates, and enumerates are failed with ERROR_ACCESS_DENIED. The assumption is this would always be treated as a benign condition, but no program does that: if you want to backup, compress, encrypt, replicate, etc, “access denied” doesn’t mean “silently ignore”, it means “fail catastophically.” To this day, programs need to be explicitly written to detect and handle these links.
2. Vista attempted to detect installers as part of UAC. If it thinks something is an installer, Vista prompts for elevation, even if the installer didn’t require Administrator access on XP. This is particularly bad when it thinks wrong – it detected Mozilla’s nsinstall.exe (which just moves files around a build tree) as an installer, so compiling Mozilla prompts for elevation. This required nsinstall.exe to be patched to indicate that it really shouldn’t require elevation (along with every installer supporting per-user installs.)
3. Having detected installers and forcing them to be Administrator, it detects an installer creating a per-user start menu shortcut and transparently makes it a system-wide shortcut. Because the start menu shows the union of both, this isn’t immediately obvious. It became obvious to my program when it didn’t perform the same translation for the uninstaller, so the installer put a file in one place, it was silently redirected somewhere else, so the uninstaller can’t find it to remove it.
4. I had a program that used monochrome icons. Windows icons record many different formats for different displays; this icon had one format, only black-and-white. Vista dropped support for black-and-white icons, but successfully loads it, and renders uninitialized memory. The solution was to upgrade the icons to 16 colors, making them four times larger with no visual change.
5. Although it’s not strictly Vista, the move to 64 bit meant that file system and registry locations are dynamically redirected for 32 bit programs, so 32 bit and 64 bit programs don’t see the same files and registry entries. This broke one piece of software I remember which queried the registry to find out how to format time and date strings, except the query was sent to the 32 bit registry while any updates are applied to the 64 bit registry, causing the program to misbehave.
malxau,
I never understood why access was denied on those directories, but I guess it was to prevent recursive loops as you say. I seem to recall that you could actually experience some of those recursive loops mounting under linux, haha.
This was a big reason I think the 64bit transition of windows was poorly executed. Rather than taking the opportunity to establish sane conventions, they created virtual mount points in the file system and registry which created more assumptions and bad practices. The whole thing was a mess and now it’s become part of windows legacy baggage. I seem to recall someone here writing a tool to detect 32 & 64bit binaries in the wrong official directories, maybe it was you? Anyways we’ve obviously had these discussions before.
http://www.osnews.com/story/28980/google-ends-32-bit-linux-support-for-chrome/
I’ve witnessed this before and didn’t understand what caused it at the time. I guess microsoft hard codes some logic to prompt for admin access for some processes. I wonder how many times UAC dialog got invoked when it wasn’t needed or desired. You’re coming at it from the false positive angle, but it’s should be noted that there are false negatives too where users would have to manually run an installer with “run as administrator” to get it to work.
Something was ultimately necessary to secure windows from all programs running as admin. Still, UAC was a very rough transition for windows. It was bound to cause some friction. Heuristic algorithms, which cause inconsistent behavior under the hood, cause inconsistency and confusion. The other obvious problem is that UAC prompts happened over and over again making it routine. Only rare events should trigger it and to this day I think microsoft still fails to disclose what exactly is triggering a UAC prompt.
Windows (and linux) are still lacking in terms of fine grained application permissions, but it’s hard to add those after the fact with so much pre-existing software.
Alfman,
Yes, that was me. The meta-point is as soon as software starts distributing binaries in multiple architectures, it doesn’t fit cleanly into the hierarchy. The Windows SDK is going to be installed in one of those Program Files, and half the binaries will be for the wrong architecture.
I hate it too, but consider how it happened. If you have a system with no fat binaries, and each program needs to find a DLL with a matching architecture, how do you express it? DLLs might be searched for in %PATH%, except you need to make sure the “correct” DLL is found, so you have to have both 32 bit and 64 bit locations and the correct one needs to be first. If you have a COM service with a full path in the registry, the 32 bit and 64 bit services would need different identities/GUIDs so that finding a DLL would be unambiguous. Anyone registering plugins via their own regkey is in for a world of hurt. There’s probably some approach to solve these by having the loader treat “wrong architecture” as “not found” and continue a path search, but the alternative ends up being just as bad as what actually happened.
The real solution is fat binaries, which solve these issues elegantly. Frustratingly, every time a new architecture is added there’s a new opportunity and a new advantage to adding support – it’s never too late to do the right thing. Windows 11 ARM64 has made some steps here, where the same DLL is used as both an x64 and ARM64 DLL, via loader magic. It’s not fully fat though because the DLL is fully ARM64 code with different x64 stub imports, so it’s not a path for developers to distribute a single binary to users. Still, at least it means x64 programs on ARM64 don’t need file system redirection.
AFAICT there’s multiple heuristics. nsinstall.exe was just a partial process name match. But it also detects things like NSIS which use a different name for every installer, so the logic is fairly sophisticated. To me this is the snowballing Windows legacy problem – any time you run a program, some code runs to check if it’s an installer. If you try to opt out by adding a manifest, well, every time you run that program, you’re running an XML parser. Obviously other platforms can create processes much faster.
Personally though it wasn’t a problem I’d had. NT had non-Admin accounts since 1993, and anyone coming from that world, with software designed for it, didn’t have issues. Even up until Windows 2000 setup required an Administrator password and a non-Administrator account – the “everyone is an Admin” thing happened in XP.
Viewed from an NT perspective, UAC is a truly ugly beast. In NT, every user is a member of some number of groups. System actions, like changing the time or rebooting, are defined by privileges, and those can be assigned to arbitrary groups. So everything is extremely granular.
When UAC comes along, a single user identity needs to be split between their “Administrator” persona and the non-Administrator persona. This can’t be done through all of the NT configuration. So the system _hard coded_ groups and privileges to remove from the user token, which broke the entire model. This is why it’s possible to have a non-Admin user create symbolic links (just assign the privilege) but it’s not possible to have a non-elevated-Admin create symbolic links, because there’s no way to assign privileges to that identity. So then we see non-Admin symbolic links get hacked in via some other opt-in mechanism a decade later. It also breaks anything where the token is ambiguous – if you SSH to a machine, which token should you get?
I really wish UAC had been expressed in terms of two linked user identities, so both could be customized, and either could be referred to explicitly (“runas /user:malxau_admin”.)
Coming from NT, this never seemed surprising or inexplicable. They happened when trying to change something a regular user couldn’t change, and anyone who’d been using privilege separation for a decade by that point would know what to expect. The system time is a system-wide, not user-specific setting, so you need to be privileged to change it.
Win7 blurred all these lines by having auto-elevation paths for certain things. This meant the number of prompts decreased, but there’s no longer a clear boundary that an unelevated admin can’t change system state. Today, even the Windows docs say “Same-desktop Elevation in UAC isn’t a security boundary”, except that’s literally the only reason for it to exist.
malxau,
I understand it, but I I think there was a simple solution sitting right in front of them: keep 32bit DLLs in system32 and put new 64bit DLLs in system64. It would have made sense, nobody would have been confused or questioned the rational, and there would have been zero incompatibilities because it was a new architecture and all new AMD64 software and compilers could follow whatever conversions microsoft defined. Instead MS focused on allowing 64bit DLLs to reside in 32bit paths, which nobody cares about. Anyways, this is all very old news, haha.
I don’t mind separate trees for different kinds of resource when appropriate, linux does that as well, the real problem was with microsoft’s directory and registry mangling creating inconsistent views of the file system. To this day programs can still “lie” to users about files missing at a location due to microsoft lying to programs…ugh. At least I understand the virtual mappings, but to normal users it’s gotta be frustrating to be told a file is missing when it’s right bloody there, haha.
Yeah, security models need to distinguish between user permissions and the processes they run. Just because *I* have permission to something doesn’t mean I want it granted to the software I run. There can be good reasons to deny permissions to software and yet most desktop operating systems don’t provide an easy way to do this.
Windows UAC was the simplest way MS had to make admin users more secure without touching the windows APIs, which was key for backwards compatibility. But I think it could have been more informative letting us know exactly what triggered it rather than just a generic “the application tried to access something, do you want to allow it?” Such vague information forces us to assume what the software is trying to do and why it needs permissions.
Yes, a lot of the UAC problems weren’t necessarily microsoft’s fault, it was just the byproduct of having to be backwards compatible. When one has to support software that is already in widespread use, it limits what one can do to make security more consistent, stronger, and easier.
Alfman,
I don’t think you’re following what I’m saying. In the scheme you’re proposing, what is the value of %PATH%?
The reason the current system works is because %PATH% contains \Windows\System32, and redirection means that different processes see different DLLs there. So without changing %PATH%, a 32 bit process will find a 32 bit DLL, a 64 bit process finds a 64 bit DLL, and there’s no way for a process to find the “wrong” DLL which would be surfaced to it as a load failure. This happens due to redirection. If redirection didn’t exist, there’d need to be some equally gross thing that ensures 32 bit and 64 bit processes get different values for %PATH%, etc.
malxau,
Why does it matter?
Right now on my 64bit windows it points to the 64bit directories.
Under 32bit processes it points to 32bit directories.
Obviously they accomplished this by mangling the directories under the same directory name, but I think the better choice would have been to use new environment variable if it was needed. Other operating systems have managed to support multiple architectures just fine without resorting to virtual directory hacks. Even microsoft themselves handled the 16bit -> 32bit transition better than from 32bit->64bit without any of this directory mangling.
No grosser than things like %ProgramW6432% and %CommonProgramW6432% that have to be used now because windows mangles paths.
https://www.tabnine.com/code/javascript/functions/builtins/ProcessEnv/ProgramW6432
It’s very problematic to have one path that leads to multiple directories. If something needs two different directories, then it merits having two different paths. Using different paths for different architectures would have been much easier to swallow than having software depend on directory mangling going forward. I know we don’t add new architectures frequently, but just think every architecture could have it’s own DLL resource path and it would be no big deal…
system_generic
system_x86_32 (system32 could be hardlinked here)
system_x86_64
system_arm_32
system_arm_64
system_ppc_64
system_mips_64
even things like this could be ok for non architectural bytecodes if you wanted to…
system_java
It’s a logical hierarchy that describes itself, what more can you ask for? New architectures would have a sensible & predictable place in the hierarchy without any need for OS mangling behind the scenes. Microsoft had a good opportunity to define whatever conventions they wanted to when AMD64 was brand new. However now that they went with one name -> multiple directories solution, it’s become long term baggage for windows with unintuitive paths that simply don’t make sense without learning the background about these hacks.
Oh well, what’s done is done, none of this matters now, haha.
Statistics hides a lot of sins. 80% of top 100 doesn’t say how that 80% is decided or by who. I’m assuming the usual age 18-26 males…
The more interesting data is what API calls are covered and how well in terms of performance and quality.
I no longer play games nor develop software and so I don’t really care much beyond the simple issue is the Proton/Wine codebase good enough to attract mainstream users to alternative platforms?
If it helps, the Wine testbot readouts show TODOs as their own category in addition to failures and successes and skips.
HollyB,
Or perhaps they’re just the most popular games on steam?
The popularity data is compiled daily here…
https://store.steampowered.com/stats/
I think that’s kind of what they were going for with their rating scale for end users:
What I find interesting is that the number of top 10 games with native clients starts at 30% and then drops to 22% for the top 1000 games. However absent a native client 60% of the top 10 games are “borked” while only 6% of the top 1000 games are borked.
This means the most popular games are slightly more likely to have a native client, but if they don’t then they are a whole order of magnitude less likely to run via proton/wine. This huge discrepency must have an explanation. Ssokolow could be right about DRM being the root cause. If the game developers engineered the game around windows kernel level DRM, then that is unlikely to ever work on linux. Pirated versions of the game with DRM removed are much more likely to work under linux, but steam cannot distribute those copies for obvious reasons.
Artem S. Tashkinov,
There’s no need for ad hominem attacks. He posted an editorial with his opinion and you disagree. That’s fine but why did you need to be so disrespectful when voicing your dissent? Maybe it’s just me, but posts attacking people like that make forums worse for the rest of us who enjoy the discussions.
My deleted comment had nothing in terms of “ad hominem” while Thom basically squarely insulted the indie developers while not spending 2 minutes to check which games actually do not run.
Of course, instead of apologizing he deleted my comment.
Artem S. Tashkinov,
Don’t be coy, you attacked him personally. Nobody on osnews deserves to be spoken to in that way. It’s unfortunate that it should even be necessary but maybe osnews should adapt rules for commenters to be respectful on the forums. You’re the one who should be apologizing but since you won’t let’s agree to disagree and leave it there.
Yeah, let’s insult everyone else, right? “We have a small dedicated ultramodern community of superior beings”, right? Wrong! You’ve forgotten about basic modesty, manners and respect.
Now tell me without being coy, polite, woke or any nonsense like that which part of this sentence sounds OK to you:
And while we are at it, tell me where exactly I said a single bad thing about the revered Thom other than asking him not to opine strongly about the things 1) he knows little to nothing about 2) he has spent 0 minutes researching.
I’m so inclined to say “**** you” but I won’t. You’re playing pretend that you’re the standard of good manners but I see nothing except denying the obvious and shifting the blame.
Artem S. Tashkinov,
I didn’t stand up for Thom because I agree with him, I did it because he deserves better and it’s the right thing to do. I don’t have any problem with the vast majority of your posts, but this post was mean-spirited. You can be persuasive without resorting to nasty personal attacks. My interest is in keeping osnews fun and friendly for everyone, that’s all. We should all try and remember the golden rule!
>> Now tell me without being coy, polite, woke or any nonsense like that which part of this sentence sounds OK to you
It all sounds ok to me.
Thom is expressing his opinion that the following types of games on Steam are garbage: indie games that have been abandoned by the developer, some games based on anime, and porn disguised as “games”.
Ultimately, his point is that, in his opinion, most of the games that are not supported in Linux are not the types of games he feels are important, which makes the headline even more impressive.
What was the point you were making in your original post? Was there a misunderstanding by Thom? Do you feel differently about the three categories of games listed above?
It’s great to observe gaming on Linux progress over the years. If things continue go in this direction for a couple more years. Then likely Linux will become the preferred choice for gaming in general.
Some points to remember:
* We are all somebody else’s idiot.
* End user perspectives are as valuable or sometimes more valuable than alleged professionals.
* You may not be as wonderful as you think you are.
* Once upon a time you were a noob.
* Try doing their job before crowing about what a kingpin holding up the future of humanity you are.
Amazing achievement. I wish I could travel in time to show it to all unbelievers back in the early 00s along with IE dominance crushed and crushed by no other than KHTML derivative and MS failing to convert its monopoly to mobile devices, and the best of all.
I think I called the Win32 API tracing thing right judging by the comments which followed later. Also judging by the comments I have no wish to be involved with the testosterone fueled slanging matches being generated. among all that there is a degree of sense being talked but it’s lost in the toxicity.
Thom may not be technical and not know all the issues but he can write. He is also representative of the general population and end users. Less toxicity would make it easier to translate knowledge into an opinion forming article i.e. good publicity and a chance of budging the needle. This matters far more in the scheme of things than any amount of importance an ego attaches to their office politics in the comments.