Wine 8.0 Released With PE Conversion Complete, Progress On WoW64 Support

[TemplarGR]

Nice response oiaohm, though my question was more towards the end users who want to remove multilib (i have seen some who just want to get rid of the libs on their system like they are a heavy burden). I understand the benefits from a distro maintainance and WINE functionality standpoint.

[oiaohm]

Nice response oiaohm, though my question was more towards the end users who want to remove multilib (i have seen some who just want to get rid of the libs on their system like they are a heavy burden). I understand the benefits from a distro maintainance and WINE functionality standpoint.

The lock step between 32 bit and 64 bit libraries can also result in end users having update issues. Distributions sometimes need issue reported to find out that they have allowed 32 bit and 64 bit to go out of alignment. So users bitten by the not synced result in something not updating they should have been causing them quite some time to workout it happened. Heavy burden is kind of there.

[amxfonseca]

Hopefully this will make possible to be able to run the official Wine package on recent versions of macOS. Since the only blocking issue was the lack of 32-bit support in modern versions of macOS (10.15+).

Glad that (non legacy) software is finally catching up on the 64-bit bandwagon.

[PluMGMK]

So if Wine is implementing WoW64 "properly" like Windows does it… Does that mean it'll start including the artificial restriction that Win16 programs can't run on 64-bit hosts? I hope not…

[dragon321]

This is more complex. There is currently no WoW64 equal on Linux for Linux native binaries but its not impossible but nothing exists.



Yes there are a lot of old games that need multilib. There is another factor here. Maintained Linux native games have 64 bit version. The older Linux native games end up needing custom runtime like particular versions of the steam runtime. Yes due to being unmaintained many cases people are recommend to use the windows version with proton because the windows version is maintained or newer.

It simple to forget items like nspluginwrapper exist. Yes it in the wrong direction with 32 bit library in 64 bit application but its the proof of concept that it can be done. When wow64 part of wine is complete the performance cost of the conversion will be able to be calculated. Interesting enough some areas WoW64 thunking end up being a performance boost because the cost is off set by more suitability designed code to take advantage of the CPU.

Valve with their runtimes already uses libcapsule to shim application using old version of library to use newer version of library.

There are a few questions that will need to be answered.
1) How many 32 bit Linux games are there that the Windows version of that game does not in fact run better in proton.
2) How popular are those games.
3) Is there possible performance gain on wrapping 32 bit application to 64 bit libraries (wow64 work with wine will provide answer to some of this )
4) Is someone like valve willing to put up the funding to develop the wrapper.

Yeah, I hope we can get something comparable for Linux native apps as well.

[oiaohm]

So if Wine is implementing WoW64 "properly" like Windows does it… Does that mean it'll start including the artificial restriction that Win16 programs can't run on 64-bit hosts? I hope not…

WOW64 support in wine makes no difference to if Win16 works or not. The win16 removal was not 100 percent artificial restriction. The espfix issue with wine and the Linux kernel shows this yes intel developer attempted to disable 16 bit protected mode back in the day with Linux kernel due to CPU design issue as well. Win16 was removed from 64 bit windows due to CPU design fault. Intel and amd funded developers due to Linux kernel rule of do not break userspace had to put in a lot of validation work to work around the CPU design fault. Yes if the do not break userspace rule did not exist and breaking this rule could equal not being allowed to submit code to the Linux kernel we would not have 16 bit protected mode in the x86 64 bit Linux kernel..

So it was not 100% artificial limitation there is a hardware fault. It was way cheaper to drop 16bit support than develop code to protect against the cpu design fault.

https://cateee.net/lkddb/web-lkddb/X86_16BIT.html Something we do have to consider is that 16bit protected mode could be removed from the Linux kernel in future like v86 was removed. Wine uses dosbox for where v86 use to be used. Emulation of some form at some point will have to be used for win16 applications winevdm on windows proves this is a valid option.

What hangover demos comes after the wow64 work is complete to have emulation hangover prototype not done win16 yet but it on it road map. So x86 windows programs on arm platform using wine win16 does not work yet.

Wine has no sign of dropping win16 support. Future win16 may be emulation only. With the CPU faults that do exist this may be the correct path forwards like it or not.

[PluMGMK]

Ah right... Is that that business where IRETQ doesn't zero the upper half of ESP when SS (?) is 16-bit? I wonder could that have been fixed with microcode instead of screwing around with OS kernels...

[Jabberwocky]

IIRC the last time I used Wine seriously was ~v1.8. There's been so many improvements that I'm considering giving it a serious attempt.

For the past decade VFIO solved most of my gaming needs. In 2022 games have started to become more hostile towards it so I've recently I started running Windows natively on my zen3/rdna2 system. I am taking the time to testing SAM / FSR / WSL2 / ASUS Armoury (and others) / AMD Adrenalin features and playing games that doesn't work with VFIO.

Unlike some other users Windows isn't the beginning and the end for me. While Windows' incredibly fast boot time and per game profiles in Adrenalin is easy and extremely useful. Graphics drivers currently have a serious bad bug, out of the box settings you getting many BSODs a day unless I use vsync driver workarounds. Yes, these are WHQL signed drivers... WSL2 is easy and fast to get going, but once you have it set up it's a mayor PITA when you are trying to anything more than a hello-world in terms of networking. Then there's privacy or complete and utter lack there of. Oh and new this week is Microsoft Edge that keeps creating desktop icons every damn time you restart your computer! Yes you can't uninstall edge and you need to use good old regedit to prevent it from making icons on your desktop. MS off to a good start in 2023.

Anyway looking forward to testing out wine again.

[oiaohm]

Ah right... Is that that business where IRETQ doesn't zero the upper half of ESP when SS (?) is 16-bit? I wonder could that have been fixed with microcode instead of screwing around with OS kernels...

The bad news was no it could not be fixed with a Microcode change. Microcode cannot in face override every part of the x86 instruction set. Yes you have the right issue.

https://lore.kernel.org/lkml/[email protected]/

Yes that the right one. Above is the 2014 where they fixed that 16-bit mode would work again.

https://lore.kernel.org/lkml/[email protected]/t/ this is the patch that killed for a while.

Yes, it does break running 16-bit apps in Wine, although Wine could be
modified to put 16-bit apps in a container. However, this is at best a
marginal use case.

That statement from the Intel developer did not go down too well for some reason in 2014.

The fix that allows 16 bit segments to be safely usable with 64 bit mode kernel took a bit of work. Yes the simple fix kill 16 bit segments end up rejected in 2014 the Linux kernel developers. At the time in 2014 wine project started looking at virtual machines for win16 and this event kind of leads into some of the work that starts hangover.

Its not a fast process getting wine to a point that virtual machine wrapping is going to be ok.

[PluMGMK]

OK, it seems I've misunderstood the scope of the problem… I thought it was just an issue with IRETQ on amd64, but it seems it goes all the way back to i386, where non-16-bit kernel-mode code is IRETting to a 16-bit user-mode CS (not SS, which I also naïvely misunderstood). I guess it was just less obvious to me since it's easier to work around the problem in 32-bit mode, and the popping of SS:ESP is conditional (whereas on 64-bit popping SS:RSP is unconditional).

It's funny how the description here (which afaik was extracted from the official docs) suggests everything works the way one would expect, e.g. ESP := Pop(); (* 16-bit pop; clear upper bits *), when actually it has never worked that way… I guess this is why Microsoft preferred to use VM86 for Win16, because IRET to VM86 always set ESP correctly?