Switch to a proper PE module

[evelikov]

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]

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]

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]

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]

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