Valve's Proton 4.2-3 Released With Wine-Mono Integration Plus DXVK 1.0.3, Updated FAudio

[Weasel]

Proton is becoming THE way for games to run on Linux. I hate to say it but I think it might be best if game devs actually "support proton" instead of native Linux. This seems odd but after having 3+ native Linux games break due to the usual dependency and library ABI hell that is Linux, I've came to the conclusion that the proton versions are actually more stable and long lived on Linux than native ones.

Amen. Applies to any application. They should just target Wine or derivatives like Proton, really.

[Weasel]

Loki Linux games from the 1990s can still be made run today when matching them up with a compatible run-time on current day distributions steam runtime in a lot of ways based off how people made runtimes for Loki Linux games to keep them working as time moved forwards.

But Wine is just 1 "runtime" and it can run apps from 1995. No need to have 1 million different runtimes.

[oiaohm]

But Wine is just 1 "runtime" and it can run apps from 1995. No need to have 1 million different runtimes.

But wine to run applications is not 1 runtime. Applications have to be installed in custom wine prefixes with the correct additions to work right.

Also date is wrong oldest games/applications that still work in wine is from windows 2.0 that is 1987.

Microsoft SxS only appears in the year 2000. Before this you had DLL hell on windows where two different applications would installed modified versions of the same dll under the same name resulting in 1 or at times both of the applications not working. This included MFC(Microsoft foundation classes) because Microsoft use to ship the source of that with their compiler. So running a pre 2000 windows application can be just as big of pain in ass as running a loki game for Linux from the same time frame as you will have todo a custom run-time per program at times.

There are no need for a million different run-times but there are more runtimes than you would be considering Weasel. Lets take Adobe on windows have you not noticed the Adobe common directory that is their common run-time to stabilise across all the different versions of windows. Steam runtime on Linux is not that different to Adobe common runtime. Fairly much all the big application developers on windows in fact make a common runtime for windows. Yet when they started attempting to make applications for Linux you see they did not do this until valve with steam. Basically Valve has treated Linux development like windows development result is it works.

Finally wine making windows API suite Linux kernel does not come without its overhead issues. So highest possible performance will not come from running in wine. Highest possible performance will come from using a native runtime. The performance difference between steam runtime and application running on distribution provided runtime is zero difference. Flatpak there is a slight over head from the security stuff but this is still less than the wine overhead.

Snap due to is usage of loopback can go and die a horrible death its performance is horrible..

Weasel if you had your facts right would have been one thing. But this is your normal facts are wrong.

There is a need for a Linux native run-time that is common for applications need highest possible performance. This explains why Valve puts well ported native game ahead of game running in proton as there is no way proton can win in performance if the program was well ported.

[Almindor]

*SNIPPED*

Basically for shipping applications on Linux Distributions use one of the runtime methods and 99.9 percent of the time you can totally ignore the distribution the user is using.

Until you run into an issue with GLIBC ABI version mismatch, dbus message format change or some compositor funkyness coz the game is trying to handle fullscreen in a "friendly way" from the X11 days.

Either way my post was more about developers. It's just easier to not bother with Linux and the really heavy burden of trying to support a closed sourced precompiled binary running in the distro hell by just targeting Windows and possibly throwing a dime in the "let's see it working in proton" look over the shoulder.

As an example of broken linux games, see anything done in adventure creator that's been released as native. Broken under wayland and many resolution setups, won't start coz engine is outdated. No issues running same thing via proton, go figure.

[Volta]

Amen. Applies to any application. They should just target Wine or derivatives like Proton, really.

To suggest one of the most broken, security vulnerable APIs over Linux one you must be clueless. Furthermore, Windows brake many older games, so to run them you have to use Wine. But the problem is it's not a single API. It's compatibility mode with NT, XP, 7 and whatever and it breaks quite often between releases. Furthermore performance is worse. Also, what both of you are suggesting is to convince developers to support MS only, but thankfully it's over now. You should just just watch TV shows instead of writing such bullshit, really.

[Weasel]

To suggest one of the most broken, security vulnerable APIs over Linux one you must be clueless.

You are delusional, boy. But be my guest start showing how the API itself is vulnerable (not its implementation which is obviously fixable and different in Wine than Windows).

Furthermore, Windows brake many older games, so to run them you have to use Wine. But the problem is it's not a single API. It's compatibility mode with NT, XP, 7 and whatever and it breaks quite often between releases. Furthermore performance is worse. Also, what both of you are suggesting is to convince developers to support MS only, but thankfully it's over now. You should just just watch TV shows instead of writing such bullshit, really.

It broke mostly games that relied on undocumented hacks.

It's not my fault that MS can design a proper stable API and the retarded Linux userland devs can't. Your TV show suggestion obviously shows up where your intelligence lies.

[Weasel]

But wine to run applications is not 1 runtime. Applications have to be installed in custom wine prefixes with the correct additions to work right.

Prefixes are not a runtime they're just stubs and dummy DLLs. Having to install correct additions is just because Wine is not complete and misses a ton of stuff.

If you have to separate two apps because they won't play nice with each other, then that is an issue with the app itself, and has nothing to do with the runtime.

[Volta]

You are delusional, boy. But be my guest start showing how the API itself is vulnerable (not its implementation which is obviously fixable and different in Wine than Windows).

Wine developers had to 'implement' Windows bugs to make it compatible.

uo broke mostly games that relied on undocumented hacks.

It's your wishful thinking. However I suppose Windows bugs weren't documented at all.

It's not my fault that MS can design a proper stable API and the retarded Linux userland devs can't. Your TV show suggestion obviously shows up where your intelligence lies.

It's not your fault Windows API is terrible from security standpoint and breaks with Windows releases. Your comments suggest you should change your shampoo, because current one washes your brain too much.

[Volta]

What your're probably trying to say is closed source application have problems with different versions of packages on Linux. This should be solved by flatpack or Ubuntu snaps. It's still possible to run Linux binaries from 91', because Linux' to userspace interface is STABLE (do not confuse with in kernel interface!). You can dream about this on Windows. Windows API isn't stable and that's why you have compatibility modes and maybe even emulation on Windows 10.

[oiaohm]

Until you run into an issue with GLIBC ABI version mismatch, dbus message format change or some compositor funkyness coz the game is trying to handle fullscreen in a "friendly way" from the X11 days.

Lets pull this apart. Old LOKI games have GLIBC ABI version mismatch and compositor funkyness from X11 stuff. dbus is too modern for Loki.

http://www.improbability.net/loki/

Those 20+ year old programs run on current day distributions using an over 6 year old run-time that has not need to be updated that often.

Linux ABI is a lot more stable if applications are shipped with runtime.

Either way my post was more about developers. It's just easier to not bother with Linux and the really heavy burden of trying to support a closed sourced precompiled binary running in the distro hell by just targeting Windows and possibly throwing a dime in the "let's see it working in proton" look over the shoulder.

Again with flatpak and steam runtime why would you be fighting with all the different distributions.

Yes steam is in provide on flathub in flatpak format and this can be useful to work around particular issues.

As an example of broken linux games, see anything done in adventure creator that's been released as native. Broken under wayland and many resolution setups, won't start coz engine is outdated. No issues running same thing via proton, go figure.

So is this a xwayland bug. Really it would be interesting to put those games in flatpak and not set wayland. Because if wayland is not set on flatpak package and x11 and the system is wayland it will use xwayland.

http://docs.flatpak.org/en/latest/sa...rmissions.html

Really adventure creator games will not work under wine if you remove the visual studio runtime they install either. So they ship with a runtime on Windows and don't ship with a runtime on Linux. Hello problem.

Please also note adventure creator games with the resolution setup issues also fail under windows it wine virtual desktop lie allows them to work under proton and nesting X11 allows the native one to work.

Basically if adventure creator games are not finding a bug in xwayland they should be able to made work converted to flatpaks. Yes at times steam installed by flatpak with sandbox permissions altered to disable wayland leaving only X11 on wayland based desktops have been a work around to get particular native games to work that have broken wayland implementations.

Final note of importance I missed is the reality is to have proton always work on any distribution you could end up using flatpak anyhow. Please note proton/wine does not support wayland out yet instead on wayland desktop is depending on xwayland.