Stefan Dösinger (@stefan) commented about dlls/user32/win.c:
+ +#ifdef __i386__ + +/* This wrapper is here to workaround a ntlea quirk. First of all, ntlea + * checks whether GetWindowLongA starts with the Win32 hotpatchable prologue, + * if it can find that, it will use a hooking strategy more difficult for us + * to deal with. Secondly, it assumes what follows the prologue is a `pushl $-2`, + * and will try to skip over this instruction when calling `GetWindowLongA`, + * (i.e. it tries to jump to `GetWindowLongA + 7`, 5 bytes for the prologue, 2 + * bytes for the `pushl`.). We have to anticipate that and make sure the result + * of doing this won't be a messed up stack, or a desynced PC. + */ +__ASM_STDCALL_FUNC( GetWindowLongA, 8, + "movl.s %edi, %edi\n" + "pushl %ebp\n" + "movl.s %esp, %ebp\n" movl.s requires a minimum GNU binutils version. I think it's been 13 or so years since I added that feature, but e.g. mac binutils does not have it. I also don't know how e.g. clang handles it when building windows binaries. A configure check might be worth adding though.
In most cases this code will be compiled by mingw-w64 with gcc and gnu binutils, which should be fine even on mac. I think the two possible configurations that could run into problems here_ 1. clang in msvc mode or mingw-clang 2. A 32 bit build targeting MacOS mojave with --without-mingw The latter is pretty tricky to pull off, so not much of a concern. Can you test the first case? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3855#note_45776