[HN Gopher] Wine 6.0
___________________________________________________________________
Wine 6.0
Author : coldpie
Score : 324 points
Date : 2021-01-14 16:12 UTC (6 hours ago)
(HTM) web link (source.winehq.org)
(TXT) w3m dump (source.winehq.org)
| amelius wrote:
| 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.
| muizelaar wrote:
| https://www.darlinghq.org/
| curt15 wrote:
| Darling
|
| Also, Microsoft previously had a project called Islandwood.
| [deleted]
| gpderetta wrote:
| Wine itself used to work fine on OSX, but dropping 32 bit
| support means a lot of programs stopped working.
| shmerl wrote:
| Now that feature freeze is over, I'm looking forward to upstream
| Wine getting spatial audio support that's needed for Cyberpunk
| 2077.
| cogman10 wrote:
| Has anyone benchmarked the vulkan switch? I'd imagine there'd be
| some pretty good performance gains.
| shmerl wrote:
| 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.
| ape4 wrote:
| Someday it will have WSL support (joke attempt)
| agumonkey wrote:
| and ie6 in win < wine < wsl < win < linux stack will still
| perform better
| DannyB2 wrote:
| At one point Wine DID work under WSL.
|
| https://news.ycombinator.com/item?id=13603451
| lights0123 wrote:
| 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.
| Koshkin wrote:
| Can confirm: it still does.
| sneakernets wrote:
| 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.
| AgentEpsilon wrote:
| 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.
| 0x0 wrote:
| 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...
| BugsJustFindMe wrote:
| CrossOver is open source. PlayOnMac uses their variant.
| shmerl wrote:
| 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.
| AgentEpsilon wrote:
| 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/
| mrpippy wrote:
| Wine on macOS can already use MoltenVK to expose Vulkan to
| Windows apps, CrossOver uses this with DXVK to support
| D3D11 games.
| shmerl wrote:
| 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.
| terramex wrote:
| 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.
| coldcode wrote:
| 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.
| wwright wrote:
| > 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.
| spijdar wrote:
| 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.
| saagarjha wrote:
| > lower end hardware
|
| > M1 MacBook Air
|
| I think you may have missed the point :P
| shmerl wrote:
| 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.
| shmerl wrote:
| Sounds interesting. So besides translating calls it also
| emulates the CPU? How does it run x86_64 games like The
| Witcher 3 on ARM?
| coldpie wrote:
| macOS on M1 provides an x86_64 emulator called Rosetta 2.
| muizelaar wrote:
| 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...
| bdefore wrote:
| 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."
| mrpippy wrote:
| 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.
| garaetjjte wrote:
| 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
| _coveredInBees wrote:
| Thanks! This worked like a charm for me.
| tadfisher wrote:
| 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.
| forgotmypw17 wrote:
| Congratulations, and thank you!
| butz wrote:
| Time to dust off those old game CDs and test them with Wine 6.
| Don't forget to leave reports in WineHQ AppDB.
| sneakernets wrote:
| 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. :-)
| iforgotpassword wrote:
| 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?
| spystath wrote:
| 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.
| bitwize wrote:
| 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.
| giomasce wrote:
| 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.
| solarkraft wrote:
| 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?
| hsbauauvhabzb wrote:
| 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).
| gpderetta wrote:
| 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.
| kekebo wrote:
| 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...
| wdb wrote:
| 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.
| marinhero wrote:
| Congratulations to the Wine team! Does this release impacts
| Steam's Proton in any way?
| ddtaylor wrote:
| Do they have one of those nice announcements where they list all
| the games that now work with it or does that come later?
| sumtechguy wrote:
| 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.
| zahrc wrote:
| PlayOnLinux and Lutris are very great platforms to see
| how/which games work on specific architecture (with setup
| scripts to easily duplicate that).
| fartcannon wrote:
| 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.
| hbiden2020 wrote:
| Hunter Biden is a pedophile - hang his fucking ass!
| Thaxll wrote:
| 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.
| chromaton wrote:
| Try PlayOnLinux.
| JoeyBananas wrote:
| Last week I played that exact game (Diablo 2) with
| playonlinux
| codetrotter wrote:
| 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.
| ciupicri wrote:
| Isn't Debian supposed to take care of all dependencies?
| MayeulC wrote:
| Maybe they didn't enable multilib (aka multiarch on Debian)?
|
| https://wiki.debian.org/Multiarch/HOWTO
| bartvk wrote:
| Isn't that CodeWeaver's version?
| confiq wrote:
| CodeWeave is another software, no?
| troyready wrote:
| 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/
| einpoklum wrote:
| 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?
| Possiblyheroin wrote:
| 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.
___________________________________________________________________
(page generated 2021-01-14 23:01 UTC)