On 11/9/22 11:46, Paul Gofman wrote:
On 11/9/22 11:20, Alexandre Julliard (@julliard) wrote:
I was actually performing some additional ad-hoc tests while doing this. I am attaching the patch which extends the test for different target process (including 32 -> 64 and vice versa). To run that I copy 32 bit ntdll_test.exe as ntdll_test32.exe along 64 bit ntdll_test.exe (to be run), and ntdll_test64.exe to the 32 bit test directory.
A more meaningful case would be to test large address aware/unaware apps of the same bitness.
I just ad-hoc tested that on top of my additional test by copying 32 bit ntdll_test.exe to ntdll_test64.exe in 32 bit test, manually setting large address aware flag on either executable, printing lpMaximumApplicationAddress from system info to make sure that all went correctly. It is the same: no failures introduced (besides unrelated part with broken return address of cource which is specific to 32 -> 64 where NtFreeVirtualMemory just succeeds this way of course).
Should I prepare that in some easier reproducible form?
I also just realized that I can actually easily straighten the HighestUserAddress setting part in wow64 vs other process by just not doing that if process is not the current process pseudo handle: that will be then set in invoke_system_apc() regardless of whether the call is processed in the same process or goes to another one.
So I guess I'll resend with that after retesting and leave the validation part (which seems to match Windows) intact?