On Wed Nov 9 11:06:29 2022 +0000, Alexandre Julliard wrote:
Same here.
Yes, here is actually the difference with Windows when wow64 is enabled (in the additional attached test that are lines 494-498 and 650-654. The check ("`if (p->HighestEndingAddress > ...`) looks correct to me in the view of the additional test above. But the limit is wrong for 32 bit source / 64 target. The difference is only when memory is allocated from 32 bit process in 64 bit process: Windows (and Wine without wow64 with my patches) allocates within the full 64 bit destination address space and returns truncated pointer to the caller. 64 bit to 32 bit allocation works like on Windows.
Unfortunately I don't yet see a clean way to do it other than maybe performing a separate wow64 APC call for other process so wow64 part is specifically handled in the target process for this case. Or, otherwise, maybe there is some way to tell NtAllocateVirtualMemoryEx that it is being called from wow64. Although I am not sure such way exists, as I understand NtAllocate functions should not care about that and this logic should be isolated in wow64 thunk.
I was thinking that maybe we can leave this bit alone for now until something depends on that working exactly like on Windows? Given the caller gets truncated (unusable) pointer is seems to me such way of allocation looks rather broken on Windows and it is not much likely any app wants to allocate target process memory without caring about resulting address which it is not going to get correctly.