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

[ZeroPointEnergy]

http://www.improbability.net/loki/

I really do have to question this. When 30 year old Linux games can still be made run on current Linux distributions using a work around that is coming up on 10 years old. 20 year old games under Windows 10 without doing work around don't work either. Wine is kind of a special case of maintaining work arounds so that 20 year old games still work. yes people have ported parts of Wine to windows to make 20 year old games work.

If you look inside valve Steam you will find a collection of 20+ year old Linux native game binaries shipped with compatibility bundle. So it about time you stop pushing this point that you cannot run old programs on Linux its simply not true. The true arguement is Linux distributions don't make it easy. Third parties like Valve are making it insanely easy to run 20-30 year old native game binaries under LInux.

They have to do it by running it in a containers or runtime and not by running it natively on the libs of your system that benefit from performance improvements and security fixes. This approach is a complete mess and comes with a lot of other issues just because the ACTUAL issue, breaking APIs of the libs that form the userland is not addressed.

Those are not solutions. Those are cheap ass band aids.

[oiaohm]

It actually isn't a problem when it comes to the kernel, because they acknowledge their role of being there for the user to run software so they have the rule to not break userland. So it is possible to do it, but that is not what we see with other libs and the issue in my opinion is the mindset of people like the one I quoted

Problem here is windows in fact breaks libraries sometimes for security you don't have a choice. Even the Linux kernel we will not break userspace rule is sometime broken because there is no other choice as well.

Valve with steam solution around old native Linux games have demoed how to use old libraries with new and get it to work. So reality is people could stop complaining about this and invest in making a front ends to make installing and using old Linux native games simple. We are past the point of this being a impossible problem we are to the point solution is well and truly demoed and proven. Its now about getting enough interested parties to get off ass and implement it.

[treba]

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

That's not quite true. XWayland does not run on plain Wayland compositors but needs extra features to get implemented by them. Wine could not just copy what XWayland does. Concerning the overhead: the fun part here is that XWayland in theory (and increasingly in practice) is faster than plain Xorg as it can make use of certain features not available in X (but in some Wayland compositors). Using hardware planes is such an example.

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

About the first part: that's a problem with the NVIDIA proprietary. The ball is on NVIDIA here (either to adopt what the other drivers are doing or proposing a better mechanism that then gets adopted by everyone). For other drivers things work just fine (better performance than on Xorg, as written above).

About the second: if you use Linux just to run Windows applications through Wine, then yes But I think that already exists, it's called ReactOS. Maybe that's for you then. Linux users are better of with a proper protocol, which is Wayland.

[oiaohm]

They have to do it by running it in a containers or runtime and not by running it natively on the libs of your system that benefit from performance improvements and security fixes.

Welcome to hell of running old games. Increasing performance can through game logic out in quite insane ways. Valve has found this one. Security fixes also can make game not work because developer of game for speed decided to break security. Also you will get cases where openssl has removed particular encryptions because they are no longer to be used because they are insecure but the game multi player protocol was written using them.

This approach is a complete mess and comes with a lot of other issues just because the ACTUAL issue, breaking APIs of the libs that form the userland is not addressed.

Sorry once you cross 15 years old of a network using application you are in complete disaster level mess where security updates will mandate API/ABI breakage sometimes way sooner as little as 10 years old can your application be busted due to mandatory security update removing encryption protocols that should not be used any more.

Those are not solutions. Those are cheap ass band aids.

Hard reality once you are to 10 years old you have cross over into the point where a container/runtime starts coming the only correct answer even under windows. Due to the fact the application over 10 years old you will know by design is most likely insecure somehow I think you should be wanting it sandboxed.

Basically like it or not software has a shelf life for how long it can be secure.

[oiaohm]

That's not quite true. XWayland does not run on plain Wayland compositors but needs extra features to get implemented by them.

I looked closer at that. Reality is XWayland does lift the bar on how much Wayland compositor need to implement in extensions. But out of all those extra extentions only 1 is specially for Xwayland. All the other are for any Wayland based application to use if they are present.

[starshipeleven]

It actually isn't a problem when it comes to the kernel

The kernel is not the whole OS

[treba]

I looked closer at that. Reality is XWayland does lift the bar on how much Wayland compositor need to implement in extensions. But out of all those extra extentions only 1 is specially for Xwayland. All the other are for any Wayland based application to use if they are present.

I can only recommend looking into all the extra code the compositors carry for XWayland
It has a reason why it's so hard to implement XWayland on demand (GS 3.34 has it as a experimental feature). And also all the hard work done so the result somewhat behaves as expected (https://gitlab.gnome.org/GNOME/mutte...e_requests/942 will be a great improvement for GS 3.36 on that front). For wine something similar would be needed (also for virtual box native mode etc.). But as there is XWayland - why bother.

[ZeroPointEnergy]

The kernel is not the whole OS

I think I remember you from past attempts to have an actual conversation that failed horribly. Looks like you only write things to be right or something or how do you explain your comment that doesn't even address anything I said. You don't have to answer, I guess we just end that here.

[aufkrawall]

No, but there is a X11 performance penalty, including on XWayland.

That is not true either, unless you are referring to zero copy presentation inside compositor (which doesn't matter with pretty much even the worst modern dGPU imaginable).

[starshipeleven]

how do you explain your comment

comparing kernel API to all userspace APIs is kind of naive as the scope is much different, and this isn't the first time I point this out, I guess it wasn't with you the last time.

Userspace stuff is using much more complex APIs on average, while kernel API is mostly doing very basic stuff that is a building block for more complex libraries.

The mere fact that not a whole lot of real applications are fully self-sufficient using only the kernel API should hint at this.