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?