Re: user32/tests: Mark built-in wndproc auto-detection behaviour as broken on Windows 8 and 10.
Huw Davies <huw(a)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. -- Dmitry.
On 23 Nov 2016, at 12:46, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Huw Davies <huw(a)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. Huw.
Huw Davies <huw(a)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. -- Dmitry.
On 23 Nov 2016, at 13:54, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Huw Davies <huw(a)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. Huw.
Huw Davies <huw(a)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. -- Dmitry.
On 23 Nov 2016, at 14:17, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Huw Davies <huw(a)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.
Huw Davies <huw(a)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.
On 23 Nov 2016, at 14:30, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote:
Huw Davies <huw(a)codeweavers.com> wrote:
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.
The reason for the test breakage is because Microsoft changed some internal bits on how window procs get the A/W affinity… And made a mess of it while doing so. Another option is to just remove this test. Huw.
participants (2)
-
Dmitry Timoshkov -
Huw Davies