https://bugs.winehq.org/show_bug.cgi?id=48641
--- Comment #5 from Paul Gofman gofmanp@gmail.com --- (In reply to qsniyg from comment #4)
2:
I can't recompile wine at the moment, but I would guess (from looking at https://github.com/hdmap/wine-hackery/blob/master/f4se) that it would be these two patches:
https://github.com/wine-mirror/wine/commit/ 1aa963efd7c7c7f91423f5edb9811f6ff95c06c0
https://github.com/wine-mirror/wine/commit/ 12be24af8cab0e5f78795b164ec8847bafc30852
If I did not miss something important, the first patch in "wine-hackery" is different from that one committed, and the committed one is not doing that tweak which could potentially make this broken hotpatcher happy. That is, the hackery patch was making the executable image allocations top down, the committed patch is not doing that. It adds support for top down allocation for NtMapViewOfSection(), but that doesn't affect how Wine loads executable.
Looking at comment https://bugs.winehq.org/show_bug.cgi?id=44893#c5 and https://bugs.winehq.org/show_bug.cgi?id=44893#c9 I suspect that the problem was not really fixed in Wine but something along the ongoing changes has tweaked the memory layout a bit. What I see in the logs is that with BottomUpAlloc patchset it seems to take the lower free memory for some previous allocations (as it is supposed to), which is later not available for the hooker's trampolines. So I am not sure yet if anything to be fixed related to the BottomUpAlloc patchset itself, or rather the original issue(s) were not really fixed in Wine and it started to work by chance, with some different memory layout / reserving handling in Wine hindered by different VirtualAlloc behaviour allocating the memory top down.
So maybe it could give some idea what we can do if you could bisect which exactly change in mainstream Wine tweaked this to work.