search

iXit / wine-nine-standalone

Build Gallium Nine support on top of an existing WINE installation
GNU Lesser General Public License v2.1
273 stars 23 forks source link

Switch to a proper PE module #130

Open evelikov opened 2 years ago

evelikov commented 2 years ago

As you may have seen, upstream wine is switching from fake PE modules to proper ones. One of the benefits is that you no longer need 32bit/multilib linux libraries.

Lower-level modules like wine-nine are usually split in a PE file on the user-side, which talks to the kernel-side linux DSO via NT style syscalls.

As of Wine 7.5 only 4 modules (of 600+) are fake-PE - openal32.dll.so, opengl32.dll.so, wineusb.sys.so, winex11.drv.so.

Please consider porting wine-nine over.

axeldavy commented 2 years ago

I admit I have been following this change in wine from very far, as I fail to see why the change matters. In the case of d3d9 most games are 32 bits, and you'll need 32 bits gallium nine anyway, right ?

But yeah I guess makes sense we switch to follow the trend.

evelikov commented 2 years ago

Err.... wrong?

The goal is to have not require 32bit/multilib gallium nine (or mesa or anything else) when the Windows programs are 32bit.

Basically: 32bit Windows game <-> 32bit wine dll <-> nt syscall <-> conversion to native <-> native (64bit) wine DSO (winex11.so) <-> native (64bit) system libraries (mesa, nine, others)

axeldavy commented 2 years ago

Hum I see.

I wonder how some details work though. How are allocations handled ? (Possibly nine will have to use wine's allocator). Is there a performance hit ?

EDIT: Also are 64bit code mapped into the 32bits program virtual space ? Because 64b code takes more space I guess, so that would be bad for the 2GB limit

evelikov commented 2 years ago

Bth I'm not 100% with the memory allocation and ownership semantics. Instead of misleading you, it would be better to check with the upstream wine team