Wine 7.16 Released With WoW64 X11 Driver Support, 20 Bug Fixes

[phoronix]

Phoronix: Wine 7.16 Released With WoW64 X11 Driver Support, 20 Bug Fixes

Wine 7.16 fell slightly off its Friday bi-weekly release train and arrived this morning...

https://www.phoronix.com/news/Wine-7.16-Releasd

[ssokolow]

brings WoW64 support to its X11 driver

Can anyone elaborate on this? The changelog isn't exactly clear either.

I know I've been running 32-bit Wine apps on 64-bit Linux under X11 so... does it reduce the need for 32-bit wine prefixes?

[simburde]

Can anyone elaborate on this? The changelog isn't exactly clear either.

I know I've been running 32-bit Wine apps on 64-bit Linux under X11 so... does it reduce the need for 32-bit wine prefixes?

It reduces the need for 32-bit libraries. If I understand it correctly WoW64 conversion is closely tied to PE conversion process in Wine. When all wine libs would be shipped in PE format with WoW64 support implemented there wouldn't be any need for 32-bit host libs. Correct me if I'm wrong.

[user1]

Yeah, I'm also waiting for the day when Wine will be able to run on purely 64 bit distro without the need for multilib. This will make some things possible like running WIne as an Appimage on Fedora Silverblue.

Currently, the only way to use Wine on Silverblue is via Bottles or Lutris Flatpaks, which is very inconvenient because all I want is to directly launch 2 or 3 Windows apps that I need, which is what Wine Appimage allows.

[Weasel]

It reduces the need for 32-bit libraries. If I understand it correctly WoW64 conversion is closely tied to PE conversion process in Wine. When all wine libs would be shipped in PE format with WoW64 support implemented there wouldn't be any need for 32-bit host libs. Correct me if I'm wrong.

That's right, but note that there will be a performance penalty compared to multilib. I'd say would be more noticeable in e.g. games, especially with the graphics API calls.

[nanonyme]

That's right, but note that there will be a performance penalty compared to multilib. I'd say would be more noticeable in e.g. games, especially with the graphics API calls.

Note that this is how basically all Windows users are running 32bit games. The penalty is completely meaningless.

[shmerl]

Can Linux native libraries do something similar to avoid 32-bit libs for games?

[Weasel]

Note that this is how basically all Windows users are running 32bit games. The penalty is completely meaningless.

Bullshit. On Windows only the things that go to actual kernel mode are ran this way, and to be honest in such case the penalty is meaningless because there's a syscall penalty even in 64-bit mode (just a bit less). ALL other libraries have 32-bit dll variants, even d3d11.dll for example (on Wine it's the same with d3d, but not with vulkan which is the backend for e.g. DXVK or Wine if you use it) and they context switch when talking to kernel mode only. i.e. drivers, but not the actual library. Wine has to go through the freaking library first.

But it's not just graphics. Look at libs like gnutls. Wine will incur penalty here, since it uses native host lib, while Windows has a complete 32-bit implementation of the fucking bcrypt or whatever the hell uses gnutls in Wine.

[oiaohm]

That's right, but note that there will be a performance penalty compared to multilib. I'd say would be more noticeable in e.g. games, especially with the graphics API calls.

This has missed something

Bullshit. On Windows only the things that go to actual kernel mode are ran this way, and to be honest in such case the penalty is meaningless because there's a syscall penalty even in 64-bit mode (just a bit less). ALL other libraries have 32-bit dll variants, even d3d11.dll for example (on Wine it's the same with d3d, but not with vulkan which is the backend for e.g. DXVK or Wine if you use it) and they context switch when talking to kernel mode only. i.e. drivers, but not the actual library. Wine has to go through the freaking library first.

But it's not just graphics. Look at libs like gnutls. Wine will incur penalty here, since it uses native host lib, while Windows has a complete 32-bit implementation of the fucking bcrypt or whatever the hell uses gnutls in Wine.

O boy you have missed something.

https://www.phoronix.com/review/ubuntu-1710-x8664/3

Yes the benchmark is is OpenSSL but it also applies to gnutls where the 64 bit version is massively faster than the 32 bit version. Yes the Instruction Set Difference is huge here. Wine usage guntls was benchmarked with hangover the result at the time was kind of different to expected. You have 32 bit x86 application running qemu being thunked to 64 bit gnutls x86 and the result is faster than the same application running on wine built for multilib. Yes it was the gnutls benchmark and other benchmarks like it with hangover resulted in thunking being pushed to mainline wine in the first place.

Also windows has a lot of encryption handling functions in kernel. https://csrc.nist.gov/csrc/media/pro.../140sp1328.pdf Windows does not have a complete 32 bit bcrypt. Yes you have 32 bit library but it syscalling out to the kernel that processed parts using 64 bit under windows. One of the reason wine has suxed in perform with 32 bit applications using bcrypt heavily is that wine has been using 32 bit instruction set instead of 64 bit for the encryption processing here.

Weasel this thunking/WoW64 bit is a true mixed bag. Yes graphical API depending on what used WoW64 can be faster. Opengl with mesa at times the 64 bit is way faster than the 32 on particular bit processing path. Even with the graphical calls it depends on what one it is. Yes there was opengl game with hangover that caused a serous what the where the game was faster with hangover than multilib as well and that was all down to how effect opengl was been processed CPU side.

Weasel remember wine has to fill in for the Windows kernel for parts the Linux kernel does not provide. The reality here is Linux native gnutls by wine is used for where microsoft own library would be calling into kernel and would change 64 bit processing from 32 bit processing. This is not the only host provided library wine is using to fill in for a role that under windows would be kernel side. The reality here lot of the changes to WoW64 under wine bring poor performance areas closer to Windows performance in that area so performance improvement.

Weasel as you said wine has to go though a library first. Big question here is should that library be 64 bit or 32bit . MS Windows does not have to answer this question because they just syscall to the kernel and have put the functionality over there.

Weasel you were not considering that multilib has a performance penalty from 32 bit ISA. So its what performance penalty is worse WoW64/thunking or the 32 bit ISA penalty. So its going to be a mixed bag that at times the WoW64/thunking will be the most performance route. gnutls and other encryption processing take a huge penalty restricting self to 32 bit ISA. Different opengl processing also takes huge penalty.

[oiaohm]

Can Linux native libraries do something similar to avoid 32-bit libs for games?

In theory yes. Problem here is this would have to be implemented from scratch. Most people don't notice that wine you run wine many other programs start like wineserver. This allows 64 bit library to run by a another application.

https://github.com/davidben/nspluginwrapper

https://github.com/osxmidi/LinVst

Yes there have been different wrappers done over time.

Remember I said in theory. With a game for example the anti cheat on the game kind could take major offense to game using library that happens to be swap out to another application that it cannot see clearly what it doing in it memory space. Remember 32 bit application and libraries run in one application memory space and 64 bit applications and libraries run in a different one. Wine just puts a IPC between 32 bit and 64 bit application. nspluginwrapper was also doing the same thing and then LinVST is doing the same thing. Most of what wine is changing with WoW64 implementation in wine is stuff that would be in windows kernel space that applications without kernel mode anti-cheat would not be able to access.