[PATCH] user32/tests: Fix a test failure on Windows < Vista.

[Zebediah Figura]

On 12/29/19 4:35 PM, Sven Baars wrote:
> On 29-12-2019 06:22, Zebediah Figura wrote:
>> On 12/28/19 3:42 PM, Sven Baars wrote:
>>> On 28-12-2019 19:09, Zebediah Figura wrote:
>>>> Signed-off-by: Zebediah Figura <z.figura12 at gmail.com>
>>>> ---
>>>>  dlls/user32/tests/winstation.c | 15 +++++++++++----
>>>>  1 file changed, 11 insertions(+), 4 deletions(-)
>>>
>>>
>>> Hey Zeb,
>>>
>>> I looked into this test failure before, and found that it used to work
>>> on Vista and XP, but then just started failing at some point. So I was
>>> trying to find the cause of this instead of just skipping the test. Did
>>> you manage to figure this out? I'm not against skipping it or something,
>>> since it may as well have been a testbot update that caused this, but
>>> I'm just curious.
>>
>> Hmm, I wasn't aware of that, no. Do you know when the failure started?
> 
> Well, the tests still succeeded in March and April it seems (at least
> sometimes):
> 
> https://web.archive.org/web/20190422232113/http://test.winehq.org/data/
> 

Thanks, that provided enough of a clue. It turns out this is a
regression in Wine, as I was able to build an earlier version of Wine
and it passed the tests on my XP VM. A bisect yielded this:

commit 60ac1cec626b63130c50b1f5c61d5fd54d185dda (HEAD, refs/bisect/bad)
Author: Alexandre Julliard <julliard at winehq.org>
Date:   Thu May 2 14:52:15 2019 +0200

    include: Use DECLSPEC_HIDDEN instead of DECLSPEC_IMPORT for dll exports.

    DECLSPEC_IMPORT interferes with delay imports on MinGW.

    Signed-off-by: Alexandre Julliard <julliard at winehq.org>

I went further, and found out the difference: in register_class(),
passing an import thunk as the lpfnWndProc field causes the test
failures. Using a simple wrapper is enough to cause test failures even
if DECLSPEC_IMPORT is used for DefWindowProcA(), so I don't think
there's a compiler bug here. Similarly, using GetProcAddress() is enough
to fix test failures if DECLSPEC_HIDDEN is used. So it seems that early
versions of windows are, for some reason, verifying the window procedure
against the actual address of DefWindowProcA().

Probably the cleanest thing to do is work around this by using
GetProcAddress().