Great summary, a few clarifications from my understanding
On 14.04.22 11:26, Eric Pouech wrote:
Keep in mind:
- the same structure can have different sizes for fields, and
different layouts when compiled for PE or ELF, 32 or 64 bit, or different CPUs. So the ELF part must handle those discrepancies if any.
- pointers will be of different sizes...
- allocation of memory can be harder to implement on ELF side (as one
must ensure that allocated memory can be accessed from 32 bit PE part)
Even on the 64-bit side, memory existing on the PE side should have been allocated through wine's system, with valid information reflected from calls to functions like NtQueryVirtualMemory.
- exception handling?
All unixlib entries have an implicit stack exception handler around them, that, when caught, returns the exception code NTSTATUS from the function to the PE side.
Actually, there will be two distinct tables:
- one used for the invocation from 64 bit PE side,
- the second one used for the invocation from 32 bit PE side.
Upon invocation, their argument will be mapped to the 32 bit or the 64 bit layout of the argument structure. This allows either to adapt the implementation to any difference between the 32 and 64 bit worlds.
This is a bit confusingly worded, the second table "__wine_unix_call_wow64_funcs" will map the incoming 32-bit ABI argument structure to the 64 bit ABI, call the 64 bit handler, then map the outgoing 64bit ABI argument structure, (the same structure is used both for input and output parameters) into the equivalent 32-bit ABI structure again.
It's still not clear to me how the new module wow64 will be activated.
As far as I understand it, wow64.dll is simply a 64-bit PE that is loaded by the 64-bit ntdll.dll in a wow64 process. 64-bit ntdll.dll also loads 32-bit ntdll.dll, which, when used on wow64, will call into wow64.dll for system calls, by means of using wow64cpu.dll to perform a context switch to the 64-bit CPU mode.