Windows steam on linux via wine

So I've wanted to switch to linux for a long time. The only thing stopping me is the fact that i cant play all of my games natively on linux. 

I would really like to know if the wine team has developed it enough so that i can play ALL of my steam games via wine, at the same, or similar speeds and settings as i do now.

A nice guide for accomplishing this, if possible, would be nice.

I played around with ubuntu a while ago, back before the unity crap was put on it. About six years ago, maybe. So if theres a better version for my needs, i would gladly be open to suggestions.

This post is mainly for a couple of people. You know who you are. You know this is your domain.

It's quite a complicated matter, and it has more to do with legal stuff and commerce than with technology, but these are the basics in my opinion (fair warning, a lot of text):

It all depends on your hardware. If you are an enthusiast, and have an AMD platform, or an Intel 2011 platform, or have a business/enterprise platform, you probably have a system that is IOMMU capable and a processor that has the hardware virtualization extensions. In that case, you can virtualize with KVM/QEMU, and you don't lose much performance (if any at all), and your virtualized system runs cleaner and controlled in its container, so in many cases you make up for that slight loss in performance, or even gain performance. Some distros make a KVM setup really simple, for instance OpenSuSE, which has Xen Hypervisor by default, which is really easy to use. If you have hardware virtualization capable hardware, and you need a guide on how to install windows in a Xen/QEMU container, I'd gladly guide you through the install. By the way, even if you use Windows, an Intel X-chipset motherboard will perform up to 30% worse in gaming framerate than a much cheaper "business class" B-chipset motherboard when using the same CPU and GPU, and that B-chipset will support IOMMU, whereas the X-chipset will not. As with so many things these days, the rule is never to buy hardware that is sold in shiny boxes or with "gamer" brandings on it, because you'll be screwed one way or the other, and you'll end up paying much more for much less. Almost all modern AMD hardware supports hardware virtualization, and so does almost all 2011-socket Intel hardware (except the extreme 2011 CPUs).

Windows as an operating system often runs faster in a container than on the metal, even in a software virtual box, a full windows install takes like 5 minutes, whereas it takes 25 minutes on the metal, because you control the environment and tell windows what to do instead of letting windows do what it wants to do. Most "gaming" rigs however, are blocked artificially as far as hardware virtualization goes, on two levels: the 1150/1155 X-platform chipsets don't support IOMMU, and the "k" CPU's, don't support hardware virtualization extensions.This is most probably done for commercial purposes, so that the "gamers" these systems are marketed towards, are locked into the commercial windows platform and can't circumvent that.

With such blocked hardware, you can't use "on the metal" virtualization, so you have to use either WINE (acronym for "Wine is not an emulator"), which translates Windows API calls to open source hardware calls, and the performance thereof depends on how good the coding of the windows application you want to run is. Most well coded applications run quite well, most sloppy coded programs run quite badly. The catch is that windows is not a high performance system, so software that wants to boost performance, like for instance the Cryengine, needs to use a lot of "tricks" to make Windows do things it was not designed to do, and those tricks don't translate well in wine, because it's obviously quite a crazy task to embed ambiguity and hacks into a universal translation layer. Wine development is accelerating, but it's mainly driven by commercial entities that want to be able to sell configuration settings for mainly windows games, but also other windows applications, mainly adobe ones.

There is a fast evolution in wine and in directX and .NET compatibility systems, those exist already, but to be honest, there aren't that much linux users interested in them, because most linux users already use much better linux native open source applications, and hyped commercial software doesn't make much of an impression. Therefore, there are very few community devs that work on windows compatibility software, and those are the devs that have the most knowledge, but they use it for other, more serious, purposes.In fact, there is more development done for the opposite, for methods to run linux native open source software on windows computers, because there is a demand for that by companies and organisations that - for whatever reason, often because it's part of their hardware leasing agreement or long term SLA - are stuck with the windows systems, but they need to use linux native open source applications to be able to evolve in their business. Popular open source applications that are part of the toolkit of service providers, are therefore often availabel in Cygwin packages, which allow for running them on a windows system.

A lot of linux users refuse to install wine-gecko for instance, which is a virtual version of internet explorer, as internet explorer is integrated in most windows software, where it fulfills unknown purposes (because it's closed source software). Like for instance, if you want to run a program like adobe lightroom, which obviously doesn't need internet explorer for user functionality, it won't run, until it thinks it finds internet explorer on the system, which is why wine-gecko makes that program think that it can still "phone home" through internet explorer, but in reality, it only provides a safe dead end. Most games will also look for internet explorer for some unclear reason, so they will also need wine-gecko to run. In windows, it's the same thing, if you uninstall internet explorer completely from windows - which can only be done by hacking the registry and deleting files, because windows won't let you uninstall internet explorer really, it will only hide it from you - your games won't run anymore, even though the Steam client for instance is not based on internet explorer, but is basically a hacked up old 32-bit version of firefox with some bling. This kind of dirty closed software tricks are part of the reason why development for making closed source software run on an open source software operating system, is not such a popular topic with open source developers, and only small groups of less experienced linux devs work on it as a specific paid job for Valve or Crossover or other commercial software houses.

As commercial software houses like Valve want to use linux for their benefit, because the old windows platform blocks their development of more potent next gen games, they are investing big bucks in those technologies, because Valve knows that its customers will still want to be able to play previously bought windows games after Steam switches to linux when they release the Steam Box, but their problem is that the basic technology already exists as open source software, so when they work on it, and pay the expense of developing it, it still stays open source, and they can't sell licenses of the software they financed, because they didn't invent it, and even if they copy it or port it, it will still stay open source. Valve thinks that it has found a solution for that, in that they will integrate the translation technology in a developers toolkit that is proprietary, but uses open source technology. They want to sell paid licenses for that developers toolkit, so when they base it on open source software, they have to do that indirectly, by first integrating the GPL-licensed open source software they want to use in Apache License 2.0-licensed open source software, and then base their proprietary closed software development kit on that AL2.0-software system, which breaks the link with the GPL licensed base software. That's why they have a deal with Canonical, whereby Canonical has agreed to make their own display server, called Mir, that breaks away from the mainstream open source development, and that is not conceived to perform as good as the mainstream GPL licensed open source display server technology, but is just conceived to provide the AL2.0 middle layer to allow Steam to build a closed source proprietary development kit on top of open source software. Canonical has already probed the market to see whether they can also monetize that AL2.0 display server for Canonical branded mobile devices, but the results of that market probe were inconclusive at best, and Canonical might still decide to sell the display server to Valve for instance, and switch to the fully open source mainstream display server, which would accelerate the development Valve can do, but would not be a good thing for the quality of the code, because as long as Canonical maintains the code, they will at least try to fix bugs and security leaks, but when a closed source commercial software house takes over the development, they will cut corners and plug the holes in the code with marketing putty, because they only want to sell, they don't care about the users.

So if you have to rely on software virtualization through a windows virtual machine, or if you have to rely on wine, there isn't a perfect solution for you yet, and there probably will never be a completely perfect solution for playing windows games in linux. A good place to start is with PlayOnLinux and winetricks, which are basically databases of wine configuration settings for windows applications, including a lot of games. Both have websites where you can look for info on how well these windows programs run on wine, even though these scores are not always up to date, and wine evolves so quickly that it often works better in reality than indicated on the websites.

Valve wanted to stimulate wine development and state trackers for linux, to make windows games instantly playable in any linux environment, and in theory, that would be a decent solution, because when the state trackers were optimized, and wine would allow for a bit more tweakability (and those two goals are not that hard to reach if experienced community devs would be interested in it), windows games could run in linux with higher performance than in windows itself... but that didn't quite work out as Valve had hoped, and the open source community still showed little interest, still because of the aformentioned dirtiness of the made-for-windows code, which is sub-standard for open source quality norms.

So the conclusion is that the only real option for game developers is to develop their games primarily for linux, and that is happening right now, where almost every week, a native linux version of a AAA game title is announced, and development is still picking up momentum. Most existing games will just be ported to linux, and be availavle for free for windows license owners, like it is now in Steam, and that's actually not such a bad deal, because you basically get a high performance linux version of the game and a regular windows version, and the player stats are synchronized through Steamplay, so if you're at a friends place and have to play on his computer with windows, you can log in and play your game with your own player stats, without having to pay anything extra, and when you play on your own linux machine, your player stats are automatically synchronized again. New games will come out on linux as primary platform, and as games cater for the enhanced possibilities of new technologies, like oculus rift and 4k display technology etc... they will have to switch to a 64-bit coding base, to be able to use more than 3.6 GB of RAM, and they will be developed for linux only, and no longer have windows support.

An important factor in the graphics performance in linux is the graphics driver for the hardware in the system. Proprietary drivers have the same game optimisations as the Windows drivers and support all of the GPUs functions, but they are closed source, and not all linux users want to taint their system. A supplementary problem here is that graphics drivers install kernel headers, so if you install proprietary graphics drivers, you "taint" your kernel with closed source code, which renders any and all possible support futile, because you can't deliver support for a system in which you can't see all of the code. The alternative is to use open source drivers. AMD has communicated its headers to the linux foundation, so these are known, and an open source driver can be made. This development of the open source AMD driver happens mainly by AMD employees, and the group of devs for the open source AMD graphics driver, is growing. AMD also makes closed source proprietary drivers for linux, which have a few more functions and perform a bit better, but the open source AMD driver gets better all the time, and strangely enough is now mostly inhibited by Intel, that has problems getting its linux drivers right, even though they only have open source drivers (but they don't have the same graphics hardware experience and want to keep their silicon low power, and that presents them with quite a couple of serious challenges). With nVidia, the situation is different: the nVidia proprietary drivers have the same functions and optimisations as their windows counterparts, but nVidia refuses to communicate the headers to the linux foundation, and refuses to support the development of an open source driver. A kickstarter campaign was organised that allowed a group of open source devs to buy nVidia graphics cards and rent an electron microsocope and a microchisel, and they photographed layer after layer of all nVidia GPU chips, reverse engineered the lithography, and made an open source driver from scratch. That produced a functional open source driver, but, nvidia GPUs will always stay at the lowest, power saving GPU frequency with the open source driver, because the community hasn't been able yet to find the mechanism nvidia uses to make the GPU clock rev up, so where the open source AMD driver performs close to the proprietary AMD driver, the nvidia open source driver performs abysmal in comparison with the proprietary nvidia driver. The other thing is that nvidia GPUs don't have much use in a linux system apart from being a graphics adapter, whereas AMD GPUs are very efficient in linux a math coprocessors, so they are not written off when the next gen of display hardware comes that won't be able to use the GPU anymore.

Another factor that makes it inevitable for future games to come out on linux instead of windows, is the fact that graphics cards are at an evolutionary dead end. GPUs are basically mathematical coprocessors, and the form factor is already absurd, and can't get much more absurd, but in the current state of technology, the complexity and power of GPUs has to increase exponentially in relation to the extra performance that can be squeezed out of them. The form factor is basically still exactly the same as in the very first IBM PCs, and that just doesn't do it anymore. Different display technology will require graphics adapters to be build into the displays instead of the PC, and in such an application, only a USB 3.0 or Thunderbolt connection with the PC is enough, and an internal ARM SoC can handle the pixel pushing much better and more efficiently than an expensive power hungry absurdly oversized GPU in the PC. In a 700 USD gaming PC, half of the budget goes up in a GPU, a mathematical coprocessor?, that's just not justifiable anymore. 4k screens will need multiple top tier super expensive GPUs to even be usable for gaming, whereas it's perfectly possible to drive these displays with a sub 100 USD dedicated ARM-based SoC in the display itself, and get a better framerate. That requires an operating system that can deal with this kind of multi-CPU load distributing computing... yup, it will only work well in UNIX-like operating systems like linux or BSD...

The logical consequence is, that at that point, with that kind of display technology, older windows games running in linux, even in wine, will actually perform better on next gen display hardware than in windows itself.

It's just an evolution. In a transitory period, you take a performance punishment in linux (not always, some games actually run faster in wine in linux than native in windows, and if you use hardware virtualization you hardly take any performance punishment at all across the board). As technology moves on, the opposite will happen, and right now, we're at that turning point, where new hardware can't break through unless it can benefit from software running natively on linux, because for instance, Asus has brought out a 4k gaming display now, but it's of little use, because someone who would buy that 3500 USD screen, would also have to invest in a dual Titan system (another 2000 USD), an strong PSU, a 2011 socket mobo, etc... to make it work for games, just to come to the conclusion that almost no windows games can benefit from a 4k display in a 16:9 display ratio on a single display, because 8 megapixel textures for one single screen can't be pushed at 60 Hz by a 32-bit game running on a deficient windows graphics API. So the transition is going to speed up considerably, because you can't stop hardware evolution. Hardware manufacturers want to sell boxes, and investing in new hardware for windows systems has become futile, as windows can't run applications anmore that won't run on 6-7 years old systems almost as well as on brand new expensive hardware, so the PC market is suffering.

So it's a complex matter and a difficult personal choice. I myself, on my main system, I just use a windows container to play windows games, and on my backup gaming PC, I use a dual boot linux/windows install, because I can't be bothered to spend time configuring stuff in a transitory period, I have better things to do, and if I want to play heavy windows games (and I don't have many of those, only BF3 and Crysis3 basically, all other modern windows games, like Bioshock, Far Cry, Tomb Raider, CoD4, BFBC, BF2, Need for Speed, etc... all seem to run just fine on my machines in wine at native screen resolutions, even on my laptops, and I don't like modern games that much anyways, I prefer the gameplay of Need for Speed Porsche 2000 challenge over the latest NFS versions for instance, and I prefer BF2 over BF3, and operation flashpoint over ArmA, etc...), I just play them in windows, which is not often at all, and I don't play them in Steam, I play them offline only anyway, as most of my games are bought on DVD, because I can buy them much cheaper that way than on Steam, because in Europe, Steam is very expensive, and especially if I shop in Belgium or Luxembourg, DVD games are much cheaper there. My favorite commercial game this year was Sniper Elite Nazi Zombie Army, and that's a pretty basic engine that works perfectly fine in wine on any of my systems. But 90% of the time that I play games, I play open source games like xonotic, redeclipse, sauerbraten, minetest, flightgear, etc... because for those I run servers where I play with my gaming friends, which are people I actually see at least weekly in real life. To be perfectly honest, I still buy commercial games, mostly in the idle hope that there is something decent to be discovered about them, but the new games that have come out after 2009, are mostly very disappointing, in that they show great graphics in the first 15 minutes of gameplay, but then revert to the same standard recycled graphics from the previous version, and gameplay of games from the XBox360 era is increasingly disappointing in my opinion, and games get ever shorter, and I can't help the feeling that they're not worth the price in comparison to older games. Last year's best games for me were Trine2 and Chivalry, those are the only ones I still want to play basically, Chivalry is just based on Unreal Engine and runs perfectly fine on wine, and Trine2 is a native linux game...

So it depends on what you want, what kind of gamer you are. I know that Wickedwig for instance refuses to use Windows, I don't, but I hardly ever need to actually use Windows, I only use it for two games that I don't really play anymore basically, and as hardware evolves, I'll be able to play those in wine also, probably better than they ever ran in windows, but I don't really care, I generally like open source gaming better anyway. It isn't until you try that you know that the actual gameplay experience in open source games is better. HIDs work snappier and more precise, especially when using advanced HIDs like flightsim joysticks, good gaming mice are more precise and are tracking faster and with less lag in linux, there are less graphics artefacts in linux games, the visual experience is more natural even if the graphics are not as elaborate, maps load in seconds or even parts of seconds, everything responds immediately, there are no server crashes or disconnects, very low ping times, no rezzing errors, no framerate drops, etc... those are things that I miss in commercial (especially windows) games, once you switch to an open source software for anything, it's very hard to turn back in my opinion. So I can't say that I crave playing windows games, I like linux native games, especially open source games, much more, but then I'm not a pixel or bling freak, I value the gaming experience and the social aspect of gaming more, and that's personal of course.

1 Like

Wow, that's a lot of information that I did not know. Haha.

Alright, thanks. I don't play many games, mostly emulation. I forgot to ask about the emulation scene on linux.

Any working ps2/gamecube emulators?

I'll probably try emulation first, for windows games, then Wine. But ill start that tomorrow. Its late here. Lol.

Thanks again for the help.