Valve Rolls Out Wine-Based “Proton” for Running Windows Games on Linux(phoronix.com)
phoronix.com
Valve Rolls Out Wine-Based “Proton” for Running Windows Games on Linux
https://www.phoronix.com/scan.php?page=news_item&px=Valve-Steam-Play-Proton-Linux
322 comments
This is good for gaming on Linux!
Future prediction: Hackers reverse engineer Microsoft SQL server for Linux compatibility DLLs and adds better Wine support. Microsoft will eventually start selling a commercial Windows 10 compatibility layer for Linux. Reason Microsoft does not found main revenue through operating sales but of online cloud adoption and subscriptions. Microsoft of today is much more open source friendly than before.
https://en.wikipedia.org/wiki/Xenix https://en.wikipedia.org/wiki/Windows_Services_for_UNIX https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux
Future prediction: Hackers reverse engineer Microsoft SQL server for Linux compatibility DLLs and adds better Wine support. Microsoft will eventually start selling a commercial Windows 10 compatibility layer for Linux. Reason Microsoft does not found main revenue through operating sales but of online cloud adoption and subscriptions. Microsoft of today is much more open source friendly than before.
https://en.wikipedia.org/wiki/Xenix https://en.wikipedia.org/wiki/Windows_Services_for_UNIX https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux
My only fear: devs will push for "just enough" Steam Play compatiblity instead of a proper Linux port. A lot of big AAA games got post-launch Linux release. These can disappear
In case anyone else is wondering, this spreadsheet is posted as one of the github issues and compiles people's tests of different games:
https://docs.google.com/spreadsheets/d/1DcZZQ4HL_Ol969UbXJmF...
https://docs.google.com/spreadsheets/d/1DcZZQ4HL_Ol969UbXJmF...
This is the corresponding github issue, open since 2012: https://github.com/ValveSoftware/steam-for-linux/issues/74 :)
At some point during the beta of the Steam client for Linux, there was a bug in that you could install Windows games on Linux. I had a binfmt_misc setup at the time, which allowed me to run Windows executables directly through Wine as if they were ordinary ELF binaries. I don't remember exactly what happened when I tried running one, I think it failed when the Steam copy protection kicked in, but I always wondered if they couldn't make this work.
At some point during the beta of the Steam client for Linux, there was a bug in that you could install Windows games on Linux. I had a binfmt_misc setup at the time, which allowed me to run Windows executables directly through Wine as if they were ordinary ELF binaries. I don't remember exactly what happened when I tried running one, I think it failed when the Steam copy protection kicked in, but I always wondered if they couldn't make this work.
> Users playing through Steam Play experiencing Linux-specific issues should be directed to Steam for support
I wonder how they'll handle user reviews. Maybe performance won't be an issue, I know some games run even faster than on Windows, but bugs that you don't know are Proton specific could lead to bad reviews.
I wonder how they'll handle user reviews. Maybe performance won't be an issue, I know some games run even faster than on Windows, but bugs that you don't know are Proton specific could lead to bad reviews.
As I said in another thread:
Congrats!
And big thanks to developers and Valve who funded dxvk, vkd3d, esync and other Wine as well as Mesa work, while contributing everything in FOSS fashion. This benefits not just Steam users but all Linux gamers.
Congrats!
And big thanks to developers and Valve who funded dxvk, vkd3d, esync and other Wine as well as Mesa work, while contributing everything in FOSS fashion. This benefits not just Steam users but all Linux gamers.
Valve really needs to roll out a 64bit client though. I always have problems just installing the client because of the 32bit architecture.
What's the driving force behind this? Is it so that Valve won't have to be dependent on microsoft or a "windows tax" for their gaming boxes? Or is it that microsoft simply wouldn't agree to license windows to them because they are already pushing xboxes? Or is it something else?
Atari is preparing the launch of its new linux console, the VCS (scheduled for next year). Apart from being a great toy for tinkering, it would be quite interesting if we could run a full steam client and some windows games on it !
Controls may be a bit hazy, but it's definitively something I would try.
Controls may be a bit hazy, but it's definitively something I would try.
This is really interesting. Would anyone have a link into more information as to how they are making this happen behind the scenes? How is this different from wine?
Valve needs to partner with Google and launch a Chromebook/Steam Machine hybrid. It's in the interest of both companies to kill Windows. Google is already adding support for native Linux programs to Chrome OS, they could make a Chrome/Android hybrid that pulls all of the weight of the Android ecosystem and adds to that the weight of Steam. It would be a success and could seriously hurt Microsoft.
Does anyone know why Valve forked the Wine rather than joining them?
Would be great if they could do that for Mac as well, although Metal is a deadend (for game devs) so they may not bother. I have had some decent success running wine games on Mac.
This could be the year of the Linux Desktop!
Why can't we just have native support... Why do almost everyone had to go for Wine instead of native support. Gaming on Wine is painful and often break with updates.
This makes GNU/Linux a more appealing and viable gaming platform than Mac OS, since it now has the opportunity to capture so many of the existing Windows games.
Samba was reverse engineered, MS somewhat tried to make it an open standard, now are agnostic to it and are still developing closed extensions.
Mono became big enough, and they opensourced their own CLR, and it runs on Linux.
DirectX was implemented as a compatibility layer and runs games at close to native speeds on Linux and MS dumps it for Vulkan. Or so the wish goes.
Mono became big enough, and they opensourced their own CLR, and it runs on Linux.
DirectX was implemented as a compatibility layer and runs games at close to native speeds on Linux and MS dumps it for Vulkan. Or so the wish goes.
This is awesome. As others have said, gaming is one of the few reasons I still use Windows on my desktop.
Glad to see Valve back to creating things other than hats and virtual trading cards
Heh, I wonder if the list is correct about its Doom games. It links to the 2016 Doom as well as DOOM II: Hell on Earth (1994). Silly trend of re-using old names for new releases, they might have mean the original Doom instead...
Has anyone addressed the possible legal issues with this type of emulation?
What about titles with strong DRM is it likely that they will run in these environments?
Oh, thank goodness. I could never get the Steam client running under Wine. Usually, nothing happens.
Does this mean we can now have wine without breaking packages and having to reinstall?
If you use Wine to play DirectX 9 games, try the d3d9 fork. It's a fork with patches that give a much increased performance with DirectX 9 games which aren't merged into the Wine mainline because of the usual bikeshedding reasons. I use it to play WoW and I get better performance than on Windows.
https://packages.gentoo.org/packages/app-emulation/wine-d3d9
https://packages.gentoo.org/packages/app-emulation/wine-d3d9
I used to be a big Wine user back when I believed in the potential for a commodity Linux desktop for normal people. These days I can’t for the life of me figure out why someone would want to run games on Wine instead of dual booting to Windows when it’s game time.
>I truly do feel that emulation of some sort is a proper technical direction for gaming on Linux. It is obviously pragmatic in the range of possible support, but it shouldn’t have the technical stigma that it does. There really isn’t much of anything special that a native port does – we still make OpenGL calls, winsock is just BSD sockets, windows threads become pthreads, and the translation of input and audio interfaces don’t make much difference (XInput and Xaudio2 are good APIs!). A good shim layer should have far less impact on performance than the variability in driver quality.
>Translating from D3D to OpenGL would involve more inefficiencies, but figuring out exactly what the difficulties are and making some form of “D3D interop” extension for OpenGL to smooth it out is a lot easier than making dozens of completely refactored, high performance native ports.
https://www.reddit.com/r/linux/comments/17x0sh/john_carmack_...