Wine 6.0 | Hacker News Reader

Wine 6.0

source.winehq.org

437 pointscoldpie93 comments

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.

It seems this is supported in CrossOver: https://www.codeweavers.com/blog/jwhite/2019/12/10/celebrati...

And it seems possible to build CrossOver wine from sources: https://github.com/Gcenx/homebrew-wine

Thanks! This worked like a charm for me.

It seems like the work to move the core modules to PE format that happened in 6.0 is work that can help bring back 32-bit support on Mac. See https://www.winehq.org/pipermail/wine-devel/2019-December/15...

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.

Some related news in the release notes:

"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."

More about Ken

https://www.startribune.com/obituaries/detail/0000379516/

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.

[0]: https://moltengl.com/moltenvk/

Wine on macOS can already use MoltenVK to expose Vulkan to Windows apps, CrossOver uses this with DXVK to support D3D11 games.

Double translation especially on a lower end hardware doesn't make it a good experience I bet. Linux is a much better option for gaming.

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?

That’s fucking incredible, man.

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.

Quinn from snazzy labs got the Witcher 3 running on an m1 MacBook Air at a blazing 40fps!

Absolute insanity how well tooling has evolved.

On what settings?

> lower end hardware

> M1 MacBook Air

I think you may have missed the point :P

I'd still consider it lower end when gaming is concerned. It's no match to a CPU + dedicated GPU set up when both are high end.

The World Of Tanks wrapper works fine for me on Big Sur with decent frame rate, not sure exactly how the GPU emulation is done however.

Sounds interesting. So besides translating calls it also emulates the CPU? How does it run x86_64 games like The Witcher 3 on ARM?

macOS on M1 provides an x86_64 emulator called Rosetta 2.

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.

CrossOver seems to have support for 32bit on Catalina through some sort of major effort. Not sure if this will trickle over to open source wine anytime soon? https://www.codeweavers.com/blog/jwhite/2019/12/10/celebrati...

CrossOver is open source. PlayOnMac uses their variant.

a humble ask for eGPU support

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.

The answer to this is Lutris - https://lutris.net/

It's a launcher that manages the dependencies needed for each individual application (setting up dedicated wine prefixes, installing any dotnet packages, etc)

Install it, then use the appropriate install script from the website: https://lutris.net/games/diablo-ii/

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.

For example: the satisfactory script just plainly doesn't work. Using the epic games store script, and then installing factorio from the store works.

The Final Fantasy XIV script also doesn't work after a new moderator decided to wipe the old ones in favor of his own.

How does this differ from PlayOnLinux?

They basically do the same thing, but lutris is much nicer with a bigger suite of options.

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:

    sudo dpkg --add-architecture i386 && sudo apt update
    sudo apt install \
      wine \
      wine32 \
      wine64 \
      libwine \
      libwine:i386 \
      fonts-wine

Notice in particular the dpkg --add-architecture i386. This enables multiarch.

NixOS has 32-bit versions of everything, and some useful shortcuts to enable for steam or wine.

You can get the wine packages from the official debian repo without any such issues.

Edit, apparently Debian 10 is buster rather than bullseye, which makes me wonder, why have you not upgraded?

Isn't Debian supposed to take care of all dependencies?

Maybe they didn't enable multilib (aka multiarch on Debian)?

https://wiki.debian.org/Multiarch/HOWTO

I usually don't have such problem. For Debian testing I'm using WineHQ builds from their repo. It also pulls all needed dependencies.

https://wiki.winehq.org/Debian

And as a side note, better don't use Debian stable for gaming. It's not a desktop distro. Debian testing / unstable is a way better option.

I'm not a gamer, but after work COVID lock-down boredom caused me to get a few old games working with Wine. Solitaire and Chess only go so far.

Tribes 2 and Test Drive 5 work great with Wine and are fun to tinker with even though they are 20+ years old now.

Steam has a lot of games that work well on linux. I play dota and have no issues. Hackmud works well too but I didn't get into it much.

There is a online database of games from steam that run on linux. I don’t game much but they ones I’ve tried have all worked for me

https://www.protondb.com/

Proton being the name of the wine fork by valve.

Try PlayOnLinux.

Last week I played that exact game (Diablo 2) with playonlinux

Isn't that CodeWeaver's version?

CodeWeave is another software, no?

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.

They are the main Wine contributors and I think Wine BDFL work for them.

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.

Time to dust off those old game CDs and test them with Wine 6. Don't forget to leave reports in WineHQ AppDB.

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?

Yes, see for example https://www.forbes.com/sites/jasonevangelho/2019/09/19/fine-....

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.

Does proton use game specific forks?

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").

no it does not

It is basically:

- wine with some additional patches (written by Codewavers themselves so they will make it to wine proper)

- DXVK and its DX12 counterpart for better direct X compat (these work fine with wine, but they are not part of wine)

- Some bridging layer to let wine programs talk with native Steam (previously you would have had to run Steam itself under wine)

You can run other programs under proton by adding them to Steam, but probably not worth it for non games.

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]

[0] https://www.gamingonlinux.com/articles/codeweavers-on-how-pr...

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. :-)

Someday it will have WSL support (joke attempt)

At one point Wine DID work under WSL.

https://news.ycombinator.com/item?id=13603451

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.

Can confirm: it still does.

and ie6 in win < wine < wsl < win < linux stack will still perform better

For the benefit of those of us who have not followed Wine and Crossover for a while...

Can someone give us a bottom line with respect to, say, the ability to run MS Office applications via Wine? With/without Crossover's product?

I have Office 365 running flawlessly with the most recent version of Crossover on Ubuntu 20.10.

The installation process seemed to fail after what felt like an hour - but the whole suite of apps just worked after a reboot - no fiddling required.

What is "Office 365"? Do you mean Office 16.0, released in 2019, or a different version?

Also - did you need to reboot your Linux host machine or perform some form of a "Wine layer reboot"?

Office 365 is a subscription service. With it you get a rolling release of Office.

I rebooted the whole PC - not sure if the Wine layer specifically would have been sufficient.

Now that feature freeze is over, I'm looking forward to upstream Wine getting spatial audio support that's needed for Cyberpunk 2077.

Congratulations to the Wine team! Does this release impacts Steam's Proton in any way?

I believe Proton's already had a lot of these patches merged for a while as they have a much more frequent update cycle

Nice, impressive project! I can still remember the days of Odin/2 which allowed you to run Windows (32b) applications in OS/2. Good times.

Is anyone working on a OSX or iOS variant of the same idea?

EDIT: in the sense that OSX or iOS programs could run on other platforms.

https://www.darlinghq.org/

Wine itself used to work fine on OSX, but dropping 32 bit support means a lot of programs stopped working.

Darling

Also, Microsoft previously had a project called Islandwood.

Has anyone benchmarked the vulkan switch? I'd imagine there'd be some pretty good performance gains.

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.

Do they have one of those nice announcements where they list all the games that now work with it or does that come later?

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.

PlayOnLinux and Lutris are very great platforms to see how/which games work on specific architecture (with setup scripts to easily duplicate that).

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.

Congratulations, and thank you!

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?

Despite being in development for so long, my experience with Wine was never smooth. At least on a Mac. Windows virtual machine is still necessary.

Good to see DSA in there. I've been using BouncyCastle for cryptography in .Net on Windows just to make it compatible with Wine.

Affinity Designer is the biggest thing holding me on Mac. I wish Wine supported it, I'd switch to PopOs in a second.

Reply on news.ycombinator.com