Fantastic work by the Wine team! Congrats on the release.
Still very disappointed that macOS has not been supported since Catalina (10.15) dropped 32-bit support - from my understanding, the 32-bit architecture is deeply integrated into Wine and removing it would be a significant effort. Understandably the focus has always been on Linux, but I would still appreciate at least an update from the team on potential macOS support in the future.
A 64-bit-only Wine builds and works normally on Catalina and Big Sur. 32-bit support exists in CrossOver’s wine but is too much of a messy hack to merge upstream. There’s hope that an upstreamable solution will be found in the future though.
"This release is dedicated to the memory of Ken Thomases, who passed away just before Christmas at the age of 51. Ken was an incredibly brilliant developer, and the mastermind behind the macOS support in Wine. We all miss his skills, his patience, and his dark sense of humor."
I think focus on Linux is also reasonable because Apple refuse to support Vulkan. I don't think Wine developers should waste their time adding Metal support in addition.
Wine developers said in the past, that they were considering dropping macOS support altogether because of issues like that.
I agree, I don't think it would be productive for the Wine team to support Metal. I do wonder how feasible it would be for MoltenVK [0] to be supported instead.
It is surprisingly solid, I have tested multiple Windows games on M1 MacBook Air through Crossover and the only one that had issues was Outer Wilds - its engine (Unity) uses geometry shaders for GPU skinning and Metal has no support for those.
They could be emulated using compute shaders, but MoltenVK does not do this at the moment. Animations work properly inside Windows VM through Parallels, so I guess this is what their proprietary driver does.
Apart from that I played Witcher 3, Sekiro and Dark Souls through CrossOver with no issues and very solid performance on basically the weakest ARM Mac that will ever exist.
But I of course agree that Linux is much better option for gaming.
> I have tested multiple Windows games on M1 MacBook Air through Crossover
So you had x64 binaries calling a DX API that called a Vulkan API that called a Metal API all on top of a JIT translation layer to ARM on two month old hardware and it worked well?
I don't have a mac anymore, but a few months back I was using crossover on catalina, and can confirm that the DX11 translation works well. I can believe that even on Rosetta it'd still work surprisingly well.
These low level graphics API wrappers have so far proven to have very little overhead. Probably because metal, vulkan, and dx12 are a lot more similar than opengl and dx9 were.
There’s also the fact that they require a lot fewer function calls to perform the same work, so what overhead there is from each call doesn’t add up as much as it used to.
The otherday I was setting up Wine on Debian to play Diablo2, it was really painful to get all the 32bits i386 version for each wine dependencies ... Once Wine was installed it worked almost flawlessly, but those i386 libs ...
Is there a way to get Wine as a single binary / docker or something that is easy to install?
Edit: As for why it was really difficult is because of that: https://wiki.winehq.org/Debian ( The WineHQ packages for Debian 10 and later require libfaudio0 as a dependency. Since the distro does not provide it for Debian 10, users of that version can download libfaudio0 packages from the OBS. See https://forum.winehq.org/viewtopic.php?f=8&t=32192 for details. ) That bloody libfaudio0.
It's a launcher that manages the dependencies needed for each individual application (setting up dedicated wine prefixes, installing any dotnet packages, etc)
Worth noting that Lutris' script repository is iffy at best. Moderators hold all the power on the platform, which means they can (and will, as they have in the past) replace entire scripts at random if they believe they have a better solution (regardless of whether it is or not, or even if it works).
Just wanted to point that out before anyone sees this great project and decides to contribute a script to an unknown game.
I remember having a bit of difficulty a few years backs too in order to get Wine installed and ready.
According to https://wiki.debian.org/Wine however it should on x86_64 in theory be as simple as the following in order to install both the 64 and 32-bit versions:
They are a company that makes crossover a solution to install manage and run windows software like playonlinux. It costs money but they also contribute to wine.
Besides the 3D graphics improvements, USB device support is a monumental change. I keep a Windows VM just to update the firmware on devices I own that will never be supported by fwupd. I suspect this is one of the many hidden requirements keeping businesses on old versions of Windows.
Since you mention games; I still don't fully understand the relation between wine and proton. It's mostly described as a wine fork optimized for games. But is it otherwise identical to wine wrt usage? Or is it integrated into steam? If it's standalone, should I even still bother trying games on wine? Does code from proton end up back in wine? Could I run other Windows apps with proton instead of wine and benefit, eg CAD software?
It is meant to be integrated into Steam, so building and using it without Steam might be a little less straightforward than pure Wine, but you can definitely do it. The launched script expects environment variables and other stuff from Steam, so it won't work without Steam. On the other hand, no other launching script is provided, but if you call the wine executable with the correct options and environment variables, it should just work.
On average I don't expect specific merits using Proton vs using vanilla Wine for non-game applications. As far as I know, Proton-specific patches are usually hacks targeted either generally at games or at specific titles. Actually, using Proton could be worse than vanilla Wine, because Proton is based on a past version of Wine which only gets updated every now and then (last Proton is based on Wine 5.13), so you are missing some development (on the other hand, sometimes developing features breaks stuff, so this could also go the other way around).
Ideally, we always want as many patches as possible to go into vanilla Wine instead of Proton or CrossOver; first because we love free software and second because maintaining forked versions is time-consuming like mad. However Wine rightly has strict code quality requirements, and sometimes developing a proper fix for some bug is either impossible or too long; those cases are handled with patches in Proton (perhaps shared with Wine Staging or CrossOver).
Disclosure: I work for CodeWeavers on Proton. Opinions my own.
I'm surprised to learn that people from CodeWeavers work on Proton. Did Valve hire your company to develop it/help out? Are you using it as a base for CrossOver or the other way around?
CrossOver and Proton are rather independent as codebases, except they're both constantly rebased on Wine. Of course patches can flow in both directions (and from either to vanilla Wine, which is the best), but AFAIK none is systematically based on the other.
I’ve always been curious, I stopped playing games shortly before steam on Linux, back then it was a mess of using various wine versions and configs on various games (or maybe I just sucked, I had far less luck getting stuff to work than others on Wine DB).
Not forks. The whole code for Proton is in https://github.com/ValveSoftware/Proton and its submodules. There are many game-specific patches, i.e., patches that were more or less explicitly included to make one specific game (or a few games) work better.
There are also some instances of game-specific behaviour: Proton detects at runtime which game is running and decides whether to enable or not some code. This is done for the most filthy hacks that are required to run something, but risk to spoil some other program. Search the code for instances of getenv("SteamAppId") or getenv("SteamGameId").
From what I understand Proton is a steam-integrated bundle of several technologies with wine being one of them.
Proton patches do seem to get upstreamed into wine[0]
Proton is Valve's Wine integrated into Steam, it's essentially vanilla Wine plus some extra patches (that will eventually work their way upstream) and libraries to make your life easier. You enable windows compatibility for a non-native game and it will run in its own prefix. If you are using Steam for games there is no real reason to use a different build of Wine although you can definitely do so. In fact different custom builds are out in the wild that can plug into Steam and be used alongside the official Valve builds.
I can't see why a third-party program cannot be used with Proton. You can just add it as an external program and enable windows compatibility as you would with a steam game.
AFAICT, Proton is a modified Wine together with Python scripts to run it, enabling hacks and features known to work well with certain games. So it's not identical from a usage standpoint to upstream Wine, but the underlying technology is the same.
Funny you say that, Lego Island, a game that required niche DX5 features to run properly and thus notoriously never worked in WINE, is finally getting addressed as of July of last year. Those issues in question (10729 and 22039 on WineHQ Bugzilla) were over a decade old, too.
So yes, please leave reports, they will get addressed, eventually. :-)
There are reports of a few games running better under Linux with Wine than natively on Windows... I wonder if when MS's DX12 translation is finished that performance increase will carry over.
Actually, there are games that run better with Wine under Windows than native... I mean, there are some games that work better when you use the OpenGL based DirectX implementation of Wine than the native Windows version, notably Dracula 3 on Windows 10 requires the "Wine D3D For Windows" project.
At one point I tried running Wine in WSL, hooked up to VcXsrv for GUI, using Qemu because WSL1 didn't support 32-bit apps. It almost worked, but audio wouldn't play, and the desktop size was wrong and parts of apps wouldn't redraw.
At least for DX9-DX11 and DX12 translation, Vulkan works great with dxvk and vkd3d-proton. If you need gaming, I'd recommend using them vs the stock support. Winevulkan itself works well.
I do not see one (does not mean it is not there). When I used to watch this project more closely you had to just goto the game db and hope someone tested it. You can also look through the commit logs and usually the reference the specific application they are fixing. The rc bits usually have the bugfixes and those too have which app that bug has fixed. They have a ranking of how good the game is. So there may have been a bug fixed but it is still broke because of 10 other things.
Protondb.com is a fantastic place to see if a game is supported on Steam through Proton. Since it's all open source, proton can also be used outside of steam.
Wine has been a wonderful piece of software when it comes to running old 16-bit Windows games and CD-ROMs of the early to mid-nineties. I can run tons of games which will never see a re-release on a modern machine without spinning up a VM.
Wine is really cool but last time I used it on my Mac I couldn’t run a program due to open gl version issues... does anyone know if/when that will be fixed?
Still very disappointed that macOS has not been supported since Catalina (10.15) dropped 32-bit support - from my understanding, the 32-bit architecture is deeply integrated into Wine and removing it would be a significant effort. Understandably the focus has always been on Linux, but I would still appreciate at least an update from the team on potential macOS support in the future.