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

[Dmitry Timoshkov]

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.

I'm more concerned about testing Windows behaviour, and staying compatible
enough. Apparently Microsoft has changed some internal bits how window procs
get the A/W affinity (and DefWindowProcA/W in particular), and I would like
to know the reason of the test breakage. Disabling the test by marking its
result as broken is usually the last resort thing after a clear understanding
what is going on.

-- 
Dmitry.