Early Out Of Tree Patches Let Wine Run Natively On Wayland

[jo-erlend]

Surely, they should call this Wineland

Wineland was the name that the vikings used for America. Knowing how the Linux community handles disagreements, it could lead to popcorn shortage.

[RahulSundaram]

It's actually the reverse, you need more maintenance for productivity applications that are updated over time while most games become static pretty quickly.

You misunderstand my point. Any single game may very well stay compatible however new games are released much more often than productivity applications and people who like those games typically aren't satisfied with other alternatives that are native to Linux so the demand for Wine to keep pace with it is high. In other words, Wine's niche has become games much more than productivity applications

[R41N3R]

It is great that somebody revives the Wine on Wayland topic. Running games on xwayland works ok, but it is not flicker free and often requires you to enable vsync. I will try the pkgbuild as soon as possible. Would be great if there would be a proton-ge like package as I rarely use wine directly these days.

[Lycanthropist]

Apart from compositors, no software uses Wayland directly; it always relies on GTK or Qt - or Wine.

This is not true. There is software that is using Wayland directly. Mostly those, that are rendering their UI themselves. For example Kodi, which uses the Wayland C++ bindings directly.

[ALRBP]

I wouldn't call Wine a compatibility layer

"Wine (recursive backronym for Wine Is Not an Emulator) is a free and open-source compatibility layer" - WineHQ/Wikipedia

[oiaohm]

Not really. Most updates in productivity applications add functionality, and this functionality usually comes from libraries or other stuff. It's very rare for a commercial application to actually do something from scratch if they can avoid it.

Most updates to commercial productivity applications are not adding functionality they are fixing crashes and translations.

https://helpx.adobe.com/au/creative-cloud/release-note/cc-release-notes.html

You can read change long of most commercial productivity applications the result is fairly much the same all the time. Most dominate change is crash fixes.

We've made other experience improvements and bug fixes. << I like weasel wording of Adobe experience improvements translate into we fixed our some text some where in our internationalisation and we are not admitting to the goof.

You stated a common miss believe that productivity applications with updates add functionality. Adding functionality to a lot of productivity applications can require businesses to have to retain staff so turns out not to be highly popular in your less main stream productivity applications. Gamers get a WoW out of new features lot of times where a lot cases with productivity applications unless the feature is exceptionally good its like not again to the point. Business will refuse to update their software from known working and trained for versions to a version with new functionality.

The users of productivity applications are a lot more conservative to new functionality than most people would guess. So bug fixing and making productivity applications as stable as possible will have customers coming back more than new features.

I am not saying new functionality don't have a place and that productivity applications should never add more new functionality. But the importance bias is different its normally better with productivity applications to collect your functionality updates together so one lot of retaining gets to do a lot. In fact like games adding access to content for those that are subscribed is more likely than new functionality for productivity applications.

Games get away with adding new functionality more often this is just the way it is.

[oiaohm]

I wouldn't call Wine a compatibility layer.

https://en.wikipedia.org/wiki/Compatibility_layer Like it or not wine is officially a Compatibility_layer.

Apart from compositors, no software uses Wayland directly; it always relies on GTK or Qt - or Wine.

Please note under X11 wine is also one of the rare items to use xlib/xcb directly. So this means wine is in a different class to most applications. Yes in this regard wine is closer to a toolkit.

Similarly no software is developed by invoking kernel system calls;

Wine is exception to that rule in a few places.

https://github.com/wine-mirror/wine/blob/6d801377055911d914226a3c6af8d8637a63fa13/loader/main.c#L129

it always uses some form of libc or other higher level library, or win32 through Wine.

Linux where syscalls are in fact fairly stable there are quite a few places were different Linux native programs go direct to syscalls.

From the OS point of view there is really not much difference between for example an ELF object compiled with GCC, loaded and launched through ld.so, and an XCOFF object compiled with Visual C++, loaded and launched through Wine.

This is mostly because of the way wine has gone about implementing things. ld.so is a loader. Wine made its own loader but there is something wacky designed into ld.so the fact that loaders are in fact stack-able this was also exploited by one of the developers who made a loader that could be embedded in ELF executable by a developer around Linux Standard Base project.

Objects made by Visual C++ are not XCOFF.

https://www.ibm.com/support/knowledgecenter/ssw_aix_72/filesreference/XCOFF.html

XCOFF and PE are both from the COFF format but they are completely different beasts. Wine does not launch XCOFF ever.

There are 3 history COFF formats. COFF from AT&T, XCOFF from IBM, ECOFF from MIPS. AT&T COFF define is generic enough that XCOFF and ECOFF could be called AT&T COFF. XCOFF and ECOFF defined mandatory features those file should have and they are absolute incompatible with each other.

Now the COFF inside a PE file or Microsoft object files is different again. Does not have the mandatory features of XCOFF or ECOFF but will go inside the AT&T generic COFF define with it own unique mandatory features .

The COFF format used by Visual C++ is in fact called "Microsoft COFF" not to be confused with XCOFF or ECOFF. COFF is one of these fun areas of computer history that insanely fragments.

[starshipeleven]

Reality is productivity applications has a lot of the same kind of thing lot of content updates low on engine changes.

Not really. Most updates in productivity applications add functionality, and this functionality usually comes from libraries or other stuff. It's very rare for a commercial application to actually do something from scratch if they can avoid it.

[oiaohm]

Not all updates are made equal.
Modern online games do "content updates" which is a completely different thing. Adding new models, skins, hats, maps and HATS and internal game mechanics (usually handled by scripting in game-specific language) and also lots of HATS hardly requires game engine changes. From the point of view of Wine, that's just another file in a folder that the game engine is reading on load.

Warframe in Wine for example does not usually care about updates as they are 99.9% content updates and not game engine updates.

Reality is productivity applications has a lot of the same kind of thing lot of content updates low on engine changes. Engine change rate in online games vs Engine change rate in productivity applications per year the online games are on average higher. Lot of productivity program changes per year are translation corrections so basically your productivity version of hats that are stored in a data format that updating does not change the program engine at all.

Not all updates are created equal in games or productivity applications. When you are talking about updates that effect wines means to run the program online multi player games are having more updates that do that on average per year than productivity applications that is just the way the numbers break down like it or not.

[jacob]

I would not call this "native", since Wine is a compatibility layer, like XWayland. This allows them to run with only one compatibility layer, Wine, instead of two, Wine+XWayland.

Also, most Linux users are still stuck with X11.

I wouldn't call Wine a compatibility layer. Apart from compositors, no software uses Wayland directly; it always relies on GTK or Qt - or Wine. Similarly no software is developed by invoking kernel system calls; it always uses some form of libc or other higher level library, or win32 through Wine. From the OS point of view there is really not much difference between for example an ELF object compiled with GCC, loaded and launched through ld.so, and an XCOFF object compiled with Visual C++, loaded and launched through Wine.