user32/tests: Mark built-in wndproc auto-detection behaviour as broken on Windows 8 and 10.

Huw Davies huw at codeweavers.com
Wed Nov 23 08:21:30 CST 2016


> On 23 Nov 2016, at 14:17, Dmitry Timoshkov <dmitry at baikal.ru> wrote:
> 
> Huw Davies <huw at codeweavers.com> wrote:
> 
>>>>>> +    SendMessageW(hwnd, WM_GETTEXT, sizeof(buf) / sizeof(buf[0]), (LPARAM)buf);
>>>>>> +    if (IsWindowUnicode(hwnd))
>>>>>> +        ok(memcmp(buf, unistring, sizeof(unistring)) == 0, "WM_GETTEXT invalid return\n");
>>>>>> +    else
>>>>>> +        ok(memcmp(buf, unistring, sizeof(unistring)) != 0, "WM_GETTEXT invalid return\n");
>>>>> 
>>>>> This doesn't look right. SendMessageW(WM_GETTEXT) is supposed to always
>>>>> return a unicode string regardless of wheather IsWindowUnicode() is broken
>>>>> or not, otherwise a lot of applications would misbehave in weird ways.
>>>>> This needs further investigation.
>>>> 
>>>> Exactly, the reason I added that bit was to show that this behaviour
>>>> is truly broken.
>>> 
>>> Sorry, but I can't believe that such a basic functionality like returning
>>> a unicode string using SendMessageW(WM_GETTEXT) is actually broken. Any UI
>>> uses it to retrieve and pass strings around for various purposes from getting
>>> username/password/regisration to getting random user input, so if it would be
>>> broken that would mean a lot of applications/installers/UI libraries/etc. were
>>> broken, and that wouldn't stay unnoticed.
>> 
>> This is a very unique situation (look at how the window in this test is created).
>> It certainly does not apply to all windows.
>> 
>> It’s difficult to know why this test was added in the first place.  Any application
>> that actually relies on this behaviour would have been broken in Windows 8.
> 
> There should be a better way of detecting broken behaviour then, in current
> form the failures just get hidden under a broken() blanket, effectively
> disabling the whole test, and making it useless. Perhaps something like
> the check for ntdll exports that's performed at the start of the test.

I don’t see why this case is any different from other similar broken behaviours.
Note that under Wine, broken is inverted, so the test is not ‘disabled' on that
platform.

Huw.





More information about the wine-devel mailing list