Wine 5.0 Released With Big Improvements For Gaming, Countless Application Fixes

[Nout]

It'll never happen. Never ever. Wayland is broken by design and can't handle the Windows GUI model.
https://bugs.winehq.org/show_bug.cgi?id=42284#c1

If you consider that a window should be allowed to resize itself, change its position on your screen, listen for keystrokes made in other applications and steal focus arbitrarily then sure. But maybe some people don't want that, and Wayland is a good alternative for them.

Also the post you linked is misinformed, AFAIK top level windows can't chose their own position and size, but they have total control over the subsurfaces they create, which includes dropdown menus and such.

[ZeroPointEnergy]

Compatibility to the stone age, with bad design decisions from decades ago, just so some proprietary apps can still run unchanged/unfixed, is not always a good idea.

Not breaking applications should be the main goal of every API. And because most people don't care about that is why Linux userland is such a fucking mess when it comes to backwards compatibility.

[Paradigm Shifter]

Windows Anti-cheat support would be a killer feature.

Sadly I doubt that will ever happen.

[treba]

Not breaking applications should be the main goal of every API. ...

No. Simply no. And by the way, what's the problem with XWayland? That is exactly the compatibility layer that allows wine application to run just fine for those that need it.

[betam4x]

XWayland is not Native Wayland, and due to that, suffers from things like high latency and lack of direct hardware acceleration (on NVIDIA at least).

At any rate, this is actually a non-issue. The only thing the author of the bug is stating is that you can't use Wayland for Window management. There is nothing stopping Wine from doing their own window management (i.e. virtual desktop mode like they have now, but rewritten for Wayland.)

That being said, if the Wayland developers don't try a bit harder to be compatible, Wayland isn't going to get very far on the desktop. There are other GPUs besides AMD and NVIDIA, and there are specific use cases that still have not been addressed.

EDIT: oh and one of the things Wine could potentially do (if they wanted) is a native Windowing system that doesn't rely on Wayland or X. Since this would be Win32/WinRT based, it could potentially kill both Wayland and Xorg.

[Templar82]

Windows Anti-cheat support would be a killer feature.

Most anti cheat software runs in Wine just fine, as in it functions exactly as designed. The problem is that the anti-cheat doesn't support Wine.

That said, there are some "Easy anti-cheat" games that work fine in Wine, so possibly the game developers have a say in how strict it should be.

[theriddick]

It would be nice if they could make more 32bit apps/games function under 64bit prefixes. Maybe work towards getting rid of the need of 32bit wine some day, there are many steam 32bit games that struggle with proton because it only supports 64bit prefixes.

[oiaohm]

I'd like to see Wayland support to avoid the XWayland performance penalty.

Problem here there is not large enough performance penalty.

https://www.phoronix.com/scan.php?page=news_item&px=Fedora-30-Xorg-vs-Wayland

There is at most under 1% performance hit for using Xwayland instead of Wayland directly. Xwayland is quite well optimised.

It'll never happen. Never ever. Wayland is broken by design and can't handle the Windows GUI model.
https://bugs.winehq.org/show_bug.cgi?id=42284#c1

The answer is that you are wrong. So was the developer to a point. Wayland can handle Windows GUI Model the proof of it is that Xwayland works.

https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xwayland-keyboard-grab/xwayland-keyboard-grab-unstable-v1.xml

This is the only extension to wayland that is specially for Xwayland and Xwayland will work without it. Yes wine native wayland would also have to use this extension to copy windows input behaviour.

Problem is wine would have to implement the Xwayland solution for screen coordinates this means having a master window/windows that you are in fact working from. Wayland protocol is designed not to give you screen coordinates but instead relative coordinates between windows. If you have not just worked out you have just implemented the biggest overhead of Xwayland.

So there is no performance reason to go after direct Wayland support with wine at this stage. Most likely wine implementation for quite some time would be worse optimised than Xwayland.

There is also no security reason to rush wine to wayland as the Windows GUI Model behaviours of being able to read stuff globally is not good security. The means to capture what is behind the pop up windows to use for transitions that windows based toolkits do and so on means the Windows GUI model is broken by design for security. So making Windows GUI model work on Wayland instead of Xwayland is not improving security either.

So its not that its impossible to put Windows GUI Model on Wayland. Its that putting Windows GUI Model direct on wayland would require a lot work for very little gain in performance with almost no gain in security.

Having developers work on multi threading sections of wine and hangover stuff both open up either more compatibility or more performance there is something to gain working on those.

Its likely wine will support Wayland one day. It would only make sense when the xwayland keyboard grab extension to wayland is stable and wine project has spare developer time to spend on a quite complex project with very little reward.

[oiaohm]

It would be nice if they could make more 32bit apps/games function under 64bit prefixes. Maybe work towards getting rid of the need of 32bit wine some day, there are many steam 32bit games that struggle with proton because it only supports 64bit prefixes.

Basically Steam/Valve is doing something nasty.

Hard reality at this time running a 32 bit application at all means with wine you are using 32 bit wine with the normal 32 bit wine libraries. The only things that are different between a 64 bit wine prefix and a 32 bit wine prefix is the directory layout and some of the values in the registry. Bad news windows to make old applications run provide these differences as well. So 32 bit wine prefix with all its layout is in fact required for many 32 bit applications to work right.

https://github.com/ValveSoftware/Proton/issues/449 there is a open bug for people wanting 32 bit prefix support.

Proton does in fact build the 32 bit wine parts. Proton setup scripts that put the valve addons into wine are not designed to use the different directories a 32 bit prefix requires them to.

https://github.com/AndreRH/hangover

Yes there is a plan to get rid of wine needing 32 bit host libraries. This will not get rid of need for 32 bit prefixes. This is likely to be poor performing for quite some time.

Basically all I can say is you need to be up valve ribs. 32 bit wine prefix support is not really optional feature if you are wanting the most application compatibility.

[muncrief]

Oh lord.

I had a hard enough time drinking 4 bottles of wine every time I played a game. Now I have to drink 5?

Doesn't anyone realize how freakin' old I am?

Oh well, I'm willing to take 5, or more, for the team if I must