Slashdot Mirror
Steam Gets Built-in Tools To Let You Run Windows Games on Linux -- Now Available in Beta (pcgamesn.com)
Steam Play -- Valve's name for its cross-platform initiative -- is getting a major update, adding built-in tools that would allow users to run Windows games on Linux. It's now available in beta. From a report: The new tools run on Proton, which is custom distribution of the widely-used Wine compatibility tool. In the most practical terms, this means you can now download and install Windows games directly from the Steam client without any further fuss. Valve is currently checking "the entire Steam catalog" and whitelisting games that run without issue, but you can turn off those guidelines and install whatever you want, too.
Proton should provide enhanced performance over Wine in many cases, according to Valve. DirectX 11 and 12 implementations are now based on Vulkan, and performance in multi-threaded games "has been greatly improved compared to vanilla Wine." You'll also see better fullscreen and controller support with Proton. It's also fully open source.
Proton should provide enhanced performance over Wine in many cases, according to Valve. DirectX 11 and 12 implementations are now based on Vulkan, and performance in multi-threaded games "has been greatly improved compared to vanilla Wine." You'll also see better fullscreen and controller support with Proton. It's also fully open source.
Working well for me so far. Windows games are installing and running. Some people are just adding the path to their Windows Steam games in the Linux Steam client and find that Steam Play is running those games!
Hopefully this doesn't give companies an excuse to ignore native Linux development.
Can this be used to run anything? Most of my applications don't run under Wine. I need to use virtualbox, which is a pain.
Iâ(TM)ve been flirting with Linux for years, but using windows only because most games donâ(TM)t run on it. If this works and works well, iâ(TM)ll probably switch
Please port it to the BSDs as well, so that I can run it on this TrueOS computer
As one with a dedicated game machine that was never going to update to Windows 10, this is a very positive outcome.
A game box with Linux will be far more useful, and likely to be on more than a couple of times a week.
Literally!
I just think it's a thing of beauty what Valve has been doing for Linux gaming this past decade.
Wine is a layer in the middle that adds some inefficiency, compatibility issues and bugs of its own.
How much more so than GTK+ as "a layer in the middle" between an application and Xlib?
The biggest issue with companies ignoring "native" Linux is they'll tend to stick with the tools for the platforms they target and they will tend towards the most modern APIs particularly for graphics where modern generally means faster and with more features.
How much of this issue goes away if a developer instructs quality control to treat Wine as a fully supported platform alongside Windows 7 and Windows 10? That's how BGB (Game Boy debugger), FCEUX (NES debugger), OpenMPT (sample based sequencer), and FamiTracker (chiptune sequencer) work: the developer ships Win32 binaries tested on both Windows and Wine.
All changes are upstreamed to the Wine project as they said in their FAQ, located here: https://store.steampowered.com... internally it's their packaged version with changes for Steam specific support but otherwise just Wine. Open source, and sources here: https://github.com/ValveSoftwa...
This is perfect for me. There is literally no reason for me to run windows except for games these days so this is great news.
Has anyone had experience with it that can comment on the performance?
The featured article is about Steam. "Linux" in the context of Steam implies a userland environment that can run applications that use Steam Runtime. This means X11/Linux on an x86-64 desktop or laptop computer, not Android or router firmware or server operating systems.
By that logic, Microsoft Office is a Linux program too.
In the sense that it's certified by its publisher to work under Wine?
And go look up, what Wine actually is. Hint: A shitload of translations from shitty quirky and even ancient toy OS APIs, to make toys run on a real OS.
And I've seen people who describe Qt as a "toy" environment, and others who describe GTK+ as a "toy" environment.
They explicitly say in the FAQ that while Wine and Proton work on Mac, they have no plans to support the Mac at this time - I wonder why not? Maybe they worry about confusing people where games have a Mac version but they could also run the Windows version via Proton...
"There is more worth loving than we have strength to love." - Brian Jay Stanley
Adding an emulation layer has been in the GoG way of doing things a long time to deal with the ancient OS. I hope this works better for them then Crossover Linux.
This is exciting news! Any word on VR games?
The benefit is they distribute the version of wine that will work, with sets of configuration files for each game, etc.
If you're running your own Wine : which it is? The Wine in the Ubuntu 16.04 repositories (1.6.x), the current Wine stable (3.0.x), the current Wine dev version (high 3.x numbers), or even the older Wine stable you installed but didn't update at 2.0.x.
if the games work? I suppose you might give up a few FPS here and there, but it's 2018 so I just don't feel the need to count every frame like I did in the 90s when I was pushing the limits at 20 fps.
Hi! I make Firefox Plug-ins. Check 'em out @ https://addons.mozilla.org/en-US/firefox/addon/youtube-mp3-podcaster/
When in reality, they're just middleware for interacting with Xlib with pretty widgets and constructs.
I remember the days before we had good toolkit libraries though. Thank god for Qt and GTK.
Some Linux diehards will say this is a backwards step because they think developers should make native games, and they worry that this will cause developers to get lazy and not bother building for anything but Windows.
But this is actually a good move by Valve. I've been tracking Linux games for a long time, and the rate of Linux game releases has flat-lined over the last two years. Initially Linux was gaining ground on Windows, in fact by mid-2016 Linux as a % of all games on Steam had reached the giddy height of 25.5% - there were 9000 Windows games and 2300 Linux games. Since then Linux has been losing ground again. The rate of new Linux games has been a virtually flat linear growth of ~100 new games a month. My conclusion from this is that the developers willing to make Linux releases are already doing so, and the rest aren't likely to. In contrast, Windows (and Mac) continued to show accelerating growth, pulling away again from Linux's linear growth. Some attribute this to the explosion of Windows gaming in China, and others attribute this to a boom in Windows shovelware. Regardless of the reason, only 20% of all games on Steam nowadays have a Linux version - next month we'll see the milestones of 5000 Linux games and 25,000 Windows games respectively
I believe Valve also noticed this trend two years ago and drew the same conclusion. I don't think it's a coincidence that all the Vulkan / Wine / DXVK work started then. It's a chicken-and-egg dilemma. They had already reached saturation in winning over developers to support Linux, and now they need to win more users. With more users will come another opportunity to win over more developers.
So yes, this is a good thing for Linux gaming.
Your clothes are a layer between your skin and people observing you.
A giraffe costume is a layer between your skin and people observing you.
Your clothes are made to fit you. They don't hide your shape or size, or make you look like something other than what you are. They are a natural fit to a human of your size and shape. They don't get in the way of using your hands and mouth, the interfaces you are designed to work with.
An giraffe costume isn't a natural fit for you, and it hides your actual size and shape. it gets in the way of using your hands and mouth naturally. It's awkward, and definitely not what you want to wear while running a race, because it slows you down.
Wine is a Windows costume for Linux, to make Linux look kinda like Windows. Rather than exposing the Linux interfaces in an organized, easy to use way as GTK does, it hides the Linux interfaces the same way a giraffe costume hides your mouth, and the result is muffled communication. GTK is designed for Linux, to fit properly on Linux, the same way your clothes are designed to fit properly on your body.
Games are literally the last bastion for Windows.... this is huge and Valve deserves our thanks.
Are you specifically talking about the Steam Client?
For some of the games, they seem like wrapped Playstation, XBox and even DOS games with Windows "mannerism", wrapping themselves alongside a 'shoddy' keyboard/ controller interface, that may or may not break during the next Steam update.
Perhaps running on Linux will bring new issues, but it may fix others such as Windows dialogs taking focus away from your games and asking you the same question over and over, despite checking the box that says "Never ask me this question again".
That usually causes your heavily armed beloved alter ego game character to suffer.
OS/2 run windows better then windows so few real os/2 apps where made and then windows got updates that did not work any more with OS/2 windows.
It will be nice have Linux games that are not tied to windows API's windows 10 is free and auto updates so can just up date our API's in a way that makes it not work on wine.
Well, with whatever patches wine accepts, or wishes to cherry-pick, at least.
09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
I'm not a gamer and I've never used Steam. But that's a platform where you don't own the games, right? If Steam went out of business, would you be able to play the games anymore?
...for older games. I've tried many old windows games that no longer work in the later versions of windows, but work out of the box in Steam Play on Linux. So for classic gaming, Steam Play on Linux could become the platform of choice. Some of the games have been removed from the steam store because they no longer work in Windows. It would be funny if they were added back to the store as Linux only games after this is out of beta.
I think Valve wants Linux/SteamOS to succeed, or at least they want it to be more successful then it is currently. A lot of people claim not to make the move because game X is not available on Linux.
This excuse won't be valid anymore.
On a long enough timeline, the survival rate for everyone drops to zero.
Wine is a layer in the middle that adds some inefficiency, compatibility issues and bugs of its own.
How much more so than GTK+ as "a layer in the middle" between an application and Xlib?
Much more, for the reason that GTK+ is a layer that provides high-level functionnality (I want a button, I want a window, I want a drop list, etc.) to the application, while itself talking to a low level interface (mostly used for blitting and rectangles filling).
What wine is doing is taking a certain low-level API and reconverting everything into a completely different low-level API.
It would be like if you took that Xlib API, but instead talking to the Xlib library it self, you talk to a separate layer that takes in Xlib API and translates it into something that is displayed using openGL, running on SDL, so that it could be used on some weird gaming console, because that GTK+ application is compiled with a GTK version hard-coded in that isn't supporting OpenGL.
Could be entirely solved by having that application built with GTK supporting OpenGL as a render back-end, but it cannot be done, because you have zero control on it, thus you need a rube goldberg layer of pancackes of middle layers to get the application working.
Wine is that adaptation layer.
That's why it would be great if eventually one day developers started to target Linux too.
But until then, there's the chicken-and-egg problem of linux not being a popular gaming platform, thus not worth spending resources on from the developers point of view, and in turn never getting popular because there are no games on it.
Thus...
How much of this issue goes away if a developer instructs quality control to treat Wine as a fully supported platform alongside Windows 7 and Windows 10? That's how BGB (Game Boy debugger), FCEUX (NES debugger), OpenMPT (sample based sequencer), and FamiTracker (chiptune sequencer) work: the developer ships Win32 binaries tested on both Windows and Wine.
Yup, developers at least starting to give attention to wine is a good intermediate step.
That at least solves the "users won't pick up linux as a platform due to lack of games" part of the equation.
And who knows, maybe this will suddenly make steam-on-linux a popular platform (maybe because it could enable cheap linux "steambox" gaming consoles ?)
And once these "steambox" gaming console become popular enough to show on the radar of the devs, some will try putting effort into true native linux builds, eventually ?
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
When STO went free to play, I started playing it on Linux. (though I was hoping for an eventual PS3/PS4 version). It performed okay, but as time went on, the performance suffered. And then Cryptic did a major update which pretty much prevented STO from running on Wine unless you compiled a bleeding edge wine install and engaged in the usual travails of getting it to work. I basically had to quit the game as a Captain 35.
I installed it via steamplay on my Fedora machine and it "just worked", though I have been spoiled by the PS4 versions faster pace, improved UI, "gambit" system, and movement/camera controls. Just ran through a mission, did a space encounter, and gained a couple of levels. Seems to be okay. At least now I'll be able to order me up a 3D printed version of my ship, PS4 version doesn't have that feature. We'd have to go the website to get a generic ship, instead of one with the name/colors/parts.
Different people have different opinions on the philosophical question of what an operating system comprises. As long as defining "operating system" is hard, defining "native" will also be hard. These questions should help determine where one might draw the line:
Is an executable loader part of "the operating system"? In Linux, executable loaders are not part of the kernel except in the special case of a statically linked ELF. Everything else, such as Wine's PE format or an ELF that uses a shared library, goes through userspace. Dynamic ELF goes through ld-linux.so.2, whereas PE goes through the kernel's "binfmt_misc" mechanism, which launches Wine once that is configured.
Is Winelib "native"? Would Wine be native if executables shipped in ELF format linked to Winelib, as opposed to relying on binary compatibility with Windows PE format? And does the answer differ any for GNUstep?
Qt apps never link to GTK+ libraries. Both Qt and GTK+ sit on top of a window manager, to which they link, in addition to many other low level libraries such as Xlib.
Likewise, Wine sits on top of a window manager, to which it links, in addition to many other low level libraries such as Xlib. In my mind, this makes Wine a widget set, little different from Qt or GNUstep.
Hardly a word of praise for Valve/Steam for saying "we're tired of waiting for devs to get on board with linux support". Instead, the inevitable debate about how Wine is better, overlooking the work it takes to keep a game working in Wine long term. Linux users have bemoaned the lack of games on the platform, give them games and they bemoan the delivery method too. If you can't do it from the command line, it's just not "real" linux i guess.
Your clothes are made to fit you.
That depends to an extent on whether you saw a tailor or bought off the rack.
They don't hide your shape or size
With exceptions. For the past several decades, a lot of money in the fashion industry has gone toward hiding the overweight brought on by the modern American diet. The loose clothing commonly associated with the Middle East hides the shape of the body for two reasons: as a side effect of "chimney effect" convective cooling design for hot weather and (allegedly) to distract the brain from sexual desire. The loose ankle-length vestments worn by Catholic clergy have a similar distractive effect. The hoop skirts popular in the 16th century and the 1860s made a woman's hips look bigger, and a reenactor told me that men preferred large hips in a wife because large hips are correlated with less risk of CPD and other complications that would interfere with birth of the pair's children.
Likewise, libraries such as Xlib and PulseAudio hide the fact that a machine has only one video output and only one stereo audio output by dividing up the video and mixing the audio from multiple applications.
An giraffe costume isn't a natural fit for you
That depends on whether you bought an off-the-shelf fursuit or commissioned a custom one.
So is Wine for the furry fandom? ;-)
It would be like if you took that Xlib API, but instead talking to the Xlib library it self, you talk to a separate layer that takes in Xlib API and translates it into something that is displayed using openGL, running on SDL
Or shorter: "an X server that uses SDL for output," like the "XServer XSDL" app for Android. That and the "GNURoot Debian" app are necessary in order to get existing applications running on some popular Linux-based distributions, as they come with Linux proper (a kernel) but not GNU or X.
GTK+ is also "a translation layer" that takes GTK+ calls and maps them onto Xlib. It also has some "quite complex logic", such as the GIO sitting on top of the Linux file system and network interfaces. And just as Wine maps Windows threads onto POSIX threads, GLib provides GLib threads that map onto POSIX threads (under Linux) or Windows threads (under Windows).
Obviously you are not a developer. As a developer Windows while painful sometimes is head and shoulders ahead of everyone else when it comes to maintaining backwards compatibility. I can develop for DX 9, 10, 11, 12 and they will all run, my sound, video and input will all work. I WISH Linux had such consistent development support.
I tried it with two games so far.
Cold Waters worked - of sorts (no fonts in the ingame UI at all, sounds distorted - unplayable)
OFP: Red River - didn't even launch.
I like the idea, but so far I'll stick to rebooting to "that other OS".
Each game can be wrapped with a specific, static build of Wine that's known for the highest level of compatibility. Lots of devs who are Wine-wrapping their games do this already; they test games in various versions of Wine and pick the most compatible one, rather than relying on the latest version installed on your distribution. These games also run in their own wineprefix, separate from your default ~/.wine directory. Valve could easily do this, too, in fact I wouldn't be surprised if that's the model they're going with already.
You're only correct when it comes to running games in Wine through the most recently updated version of /usr/bin/wine you've got installed on your distribution today. It's a completely different situation when working with wrapped games packaged by development teams who have been thorough in their compatibility research. Those games will run well very consistently.
Installing a GTK+ app or installing a Qt app.
If an app's developer or distributor explicitly supports use of the app in Wine, you can add "installing a Wine app" to that list. The featured article is about a distributor adding such support.
Not only am I fairly sure that's now how the software stack looks so the latter may not exist/disappear and the software can still function
Likewise, Wine's GDI is flexible enough to be adapted to Wayland or other non-X graphics stacks.
If someone still uses sharepoint, he have no idea what is doing nor why, he just throw some money to a problem and hope it solved it. If it is mission critical, it should never use sharepoint !
Higuita
I have bought many Humble Bundles over the years, and while there have been a lot of games available for Linux, there have been quite a few "steam/windows only" games that I haven't been able to play. My kids' computers run Win7. I have been disappointed that more and more games in bundles are "steam-only" instead of DRM-free like in the beginning. For the most part because my kids all use my steam account because that is what the games are linked to. But there are challenges with that approach (one logged in online at a time).
I was very hesitant about Steam originally, I still am not comfortable with having to run Steam in order to play a game that I bought. While this move will allow me to play more games that I already own, it still makes me cautious about getting locked into how Steam controls things.
My beliefs do not require that you agree with them.
I run SteamOS on my router, you insensitive clod!
Does this mean next year will be the year of the Linux desktop?
Linux itself can load only static ELF (and static a.out, which is obsolete). An executable in PE format is not "native compiled" in the sense that it has to be loaded into RAM by the userspace program wine. Likewise, an executable in dynamically linked ELF format is not "native compiled" in the sense that has to be loaded into RAM by the userspace program ld-linux.so.2. But once the program is loaded, there is no interpretation or dynamic translation of x86 or x86-64 instructions, just library calls.
We appear to disagree on definitions. In order to help me (and other readers) understand the definitions that you are implicitly assuming, please answer me this: If a program is shipped as a dynamically linked ELF that uses Winelib, would you consider it "native compiled"? Why or why not?