Wine 7.0-rc3 Released With 22 More Fixes

[phoronix]

Phoronix: Wine 7.0-rc3 Released With 22 More Fixes

While off the usual Friday release regiment due to the Christmas holidays, Wine 7.0-rc3 was released minutes ago as the newest test release for this open-source software enabling Windows games and applications to run on Linux...

https://www.phoronix.com/scan.php?pa...x=Wine-7.0-rc3

[birdie]

Another quite serious recent regression has been fixed:

52225 Several games suffer from audio crackling due to underflows in winepulse.drv

[birdie]

Meanwhile you thought we hadn't had enough DEs and its forks under Linux?

Wait, here's another one (instead of fixing bugs in KDE Gnome Mate Cinnamon XFCE LXQT Enlightenment Deepin Budgie ... etc.)

Meat Maui Shell: https://github.com/Nitrux/maui-shell

[user1]

Meat Maui Shell: [URL="https://github.com/Nitrux/maui-shell"]https://github.com/Nitrux/maui-shell

That looks like a really tasty meat. I'm hungry now

[MastaG]

I always wonder when I see the never ending list of bugs that have been fixed, where the original fixes came from and to what degree they are shared among the popular forks such as proton and codeweavers.

For example I can imagine fixes for popular video games are most likely contributed or backported from Proton or codeweavers?
If not, how fast would they include them?
For example is it's a game available on Steam they would most likely be cherry picked fast for Proton I guess?

[birdie]

I always wonder when I see the never ending list of bugs that have been fixed, where the original fixes came from and to what degree they are shared among the popular forks such as proton and codeweavers.

For example I can imagine fixes for popular video games are most likely contributed or backported from Proton or codeweavers?
If not, how fast would they include them?
For example is it's a game available on Steam they would most likely be cherry picked fast for Proton I guess?

Win32 contains hacks upon hacks upon workarounds for various broken/incorrectly coded applications, so fixes come from various developers trying to fix certain applications. This often however leads to other applications getting broken. Unfortunately, this process will never be completed because only Microsoft can complete it by releasing all the hacks. Tons of people outside of Microsoft have access to Windows source code but Wine developers cannot use this code and AFAIK if they see the Windows source code they are not allowed to send bugfixes to Wine. It's clean-room design/reverse engineering or bust.

As to bugfixes from Proton to Wine? I haven't heard about that many, Proton is basically Wine Staging + DXVK, so whatever fixes prove to be good in Staging are slowly migrating back to Wine.

[middy]

Win32 contains hacks upon hacks upon workarounds for various broken/incorrectly coded applications, so fixes come from various developers trying to fix certain applications. This often however leads to other applications getting broken. Unfortunately, this process will never be completed because only Microsoft can complete it by releasing all the hacks. Tons of people outside of Microsoft have access to Windows source code but Wine developers cannot use this code and AFAIK if they see the Windows source code they are not allowed to send bugfixes to Wine. It's clean-room design/reverse engineering or bust.

As to bugfixes from Proton to Wine? I haven't heard about that many, Proton is basically Wine Staging + DXVK, so whatever fixes prove to be good in Staging are slowly migrating back to Wine.

really crazy that microsoft on the other hand is able to reign free getting linux and linux applications working on windows. from first with WSL and now WSL2 + sending in code to getting 3d acceleration working with it. granted WSL2 is a hypervisor but they can easily hack wtih linux bits, but because they "see" windows source code they cannot contribute to wine.

its a one way street. pet peeve of mine every time i see microsoft spout microsoft <3 linux. microsoft, if you really do, then put your foot where your mouth is. make it that you can contribute to wine if you see the windows source code. actually contribute to making your stuff work on linux like you are making linux stuff work on windows. i really wish that movement in the 1990's to make windows API an open, public standard didn't collapse.

[Weasel]

As to bugfixes from Proton to Wine? I haven't heard about that many, Proton is basically Wine Staging + DXVK, so whatever fixes prove to be good in Staging are slowly migrating back to Wine.

Proton is way more than that, but in general, devs who work on Proton try to upstream their fixes AFAIK. There's a lot of bugfixes that are only in Proton but not upstream simply because they are not reviewed and ignored (the reason wine-staging started in the first place too), or are too much of a hack or not deemed "clean enough" for upstream.

Sometimes problem fixes just can't be "clean enough" and honestly this policy is kind of stupid. Functionality trumps code cleanness. Always. But whatever.

[pal666]

As to bugfixes from Proton to Wine? I haven't heard about that many

it means you never read proton changelog which has entries like "Updated Wine to version 5.13. 256 changes in Proton 5.0 were either upstreamed or are no longer needed."

Proton is basically Wine Staging + DXVK

in real world outside of your imagination proton is basically more than a dozen components, including valve fork of wine

[Michael_S]

I've seen a lot of blog posts over the years bemoaning that many free software library projects, like GTK, KDE Frameworks, and countless others, keep changing their APIs and ABIs as they evolve. It's within their rights for the developers to do that, and we the users have no right to demand otherwise. But it makes it more difficult for application developers and distribution maintainers to package applications. Every time there is a breaking change, they have to modify the application.

Conversely Microsoft's business interests motivated them to put a lot of effort into backwards compatibility. It's not perfect, but it might be more consistent than common libraries on Linux.

So I will make the joke here that maybe Wine 9 or Wine 10 will be a better foundation for common Linux desktop applications than GTK or KDE Frameworks, at least in the eyes of application developers and distribution maintainers. Once a Windows API is supported in Wine, the support is usually stable going forward.

Meanwhile you thought we hadn't had enough DEs and its forks under Linux?

Wait, here's another one (instead of fixing bugs in KDE Gnome Mate Cinnamon XFCE LXQT Enlightenment Deepin Budgie ... etc.)

Meat Maui Shell: https://github.com/Nitrux/maui-shell

I don't see how that's relevant here. As long as the project developers comply to their FOSS license terms, they can do whatever they want.

I'm more annoyed when popular desktop environments make breaking changes to features or APIs. If some hobby desktop with a few hundred users is changed, who cares? But again, even in the case of GNOME, KDE, Cinnamon, etc... I can be annoyed but I can't attack the developers for their choice. The license I agreed to when I accepted their software makes it clear that there's no warranties and no guarantees. The only real option I have if I don't like a change is to switch desktops or fork the project. Anything else is trolling.