[PATCH 0/2] MR4876: user32/tests: Test GetKeyboardLayout() in CJK locales.

[Zhiyi Zhang (＠zhiyi)]

GetKeyboardLayout() is also tested manually on Windows 10 with Korean, Chinese, and Japanese IME
activated.

[PATCH 1/2] user32/tests: Test GetKeyboardLayout() in CJK locales.

[Zhiyi Zhang]

From: Zhiyi Zhang

GetKeyboardLayout() is also tested manually on Windows 10 with Korean, Chinese, and Japanese IME
activated.
---
 dlls/user32/tests/input.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/dlls/user32/tests/input.c b/dlls/user32/tests/input.c
index 12fa459205a..5f68f34443a 100644
--- a/dlls/user32/tests/input.c
+++ b/dlls/user32/tests/input.c
@@ -5420,6 +5420,24 @@ static void test_input_desktop( char **argv )
     ok_ret( 1, SetCursorPos( pos.x, pos.y ) );
 }

+static void test_GetKeyboardLayout(void)
+{
+    LANGID lang_id;
+    BOOL is_cjk;
+    HKL hkl;
+
+    /* Test that the high word of the keyboard layout in CJK locale on Vista+ is the same as the low
+     * word, even when IME is on */
+    lang_id = PRIMARYLANGID(GetUserDefaultLCID());
+    is_cjk = (lang_id == LANG_CHINESE || lang_id == LANG_JAPANESE || lang_id == LANG_KOREAN);
+    if (is_cjk && LOBYTE(LOWORD(GetVersion())) > 5)
+    {
+        hkl = GetKeyboardLayout(0);
+        todo_wine
+        ok(HIWORD(hkl) == LOWORD(hkl), "Got unexpected hkl %p.\n", hkl);
+    }
+}
+
 START_TEST(input)
 {
     char **argv;
@@ -5465,6 +5483,7 @@ START_TEST(input)
     test_RegisterRawInputDevices();
     test_rawinput(argv[0]);
     test_DefRawInputProc();
+    test_GetKeyboardLayout();

if(pGetMouseMovePointsEx)
         test_GetMouseMovePointsEx( argv );

[PATCH 2/2] win32u: Don't set the high word of keyboard layout to 0xe001 in CJK locales on Vista+.

[Zhiyi Zhang]

From: Zhiyi Zhang

The high word of the keyboard layout in CJK locale on Vista+ is the same as the low word, even when
IME is on according to tests in user32 and manual tests on Windows 10.

Fix Super Robo Wars 30 (SteamID: 898750) crash on start when CJK locales are used.
---
 dlls/user32/tests/input.c |  1 -
 dlls/win32u/input.c       | 15 ++++++++++-----
 2 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/dlls/user32/tests/input.c b/dlls/user32/tests/input.c
index 5f68f34443a..7c1de6e6ccb 100644
--- a/dlls/user32/tests/input.c
+++ b/dlls/user32/tests/input.c
@@ -5433,7 +5433,6 @@ static void test_GetKeyboardLayout(void)
     if (is_cjk && LOBYTE(LOWORD(GetVersion())) > 5)
     {
         hkl = GetKeyboardLayout(0);
-        todo_wine
         ok(HIWORD(hkl) == LOWORD(hkl), "Got unexpected hkl %p.\n", hkl);
     }
 }
diff --git a/dlls/win32u/input.c b/dlls/win32u/input.c
index 3ee46f0bfcf..9894636ef82 100644
--- a/dlls/win32u/input.c
+++ b/dlls/win32u/input.c
@@ -927,18 +927,23 @@ static HKL get_locale_kbd_layout(void)
      */

NtQueryDefaultLocale( TRUE, &layout );
+    layout = MAKELONG( layout, layout );

/*
      * Microsoft Office expects this value to be something specific
      * for Japanese and Korean Windows with an IME the value is 0xe001
      * We should probably check to see if an IME exists and if so then
      * set this word properly.
+     *
+     * On Vista+, the high word is always layout, not 0xe00* even when IME is on.
+     * Super Robo Wars 30 (SteamID: 898750) depends on it.
      */
-    langid = PRIMARYLANGID( LANGIDFROMLCID( layout ) );
-    if (langid == LANG_CHINESE || langid == LANG_JAPANESE || langid == LANG_KOREAN)
-        layout = MAKELONG( layout, 0xe001 ); /* IME */
-    else
-        layout = MAKELONG( layout, layout );
+    if (NtCurrentTeb()->Peb->OSMajorVersion <= 5)
+    {
+        langid = PRIMARYLANGID( LANGIDFROMLCID( layout ) );
+        if (langid == LANG_CHINESE || langid == LANG_JAPANESE || langid == LANG_KOREAN)
+            layout = MAKELONG( layout, 0xe001 ); /* IME */
+    }

return ULongToHandle( layout );
 }

[PATCH 2/2] win32u: Don't set the high word of keyboard layout to 0xe001 in CJK locales on Vista+.

[Marvin]

Hi,

It looks like your patch introduced the new failures shown below.
Please investigate and fix them before resubmitting your patch.
If they are not new, fixing them anyway would help a lot. Otherwise
please ask for the known failures list to be updated.

The tests also ran into some preexisting test failures. If you know how
to fix them that would be helpful. See the TestBot job for the details:

The full results can be found at:
https://testbot.winehq.org/JobDetails.pl?Key=142063

Your paranoid android.

=== w10pro64 (32 bit report) ===

user32:
input.c:4604: Test failed: 8:0: WaitForSingleObject returned 258
input.c:4548: Test failed: 8:0: expected that X highest bit is set, got 0x1
input.c:4549: Test failed: 8:0: expected that X keystate is set
input.c:4549: Test failed: 8:0: expected that X keystate is set
input.c:4556: Test failed: 8:0: expected that X keystate is set
input.c:4556: Test failed: 8:0: expected that X keystate is set
input.c:4548: Test failed: 8:1: expected that X highest bit is set, got 0
input.c:4549: Test failed: 8:1: expected that X keystate is set
input.c:4549: Test failed: 8:1: expected that X keystate is set
input.c:4556: Test failed: 8:1: expected that X keystate is set
input.c:4556: Test failed: 8:1: expected that X keystate is set
input.c:4548: Test failed: 8:2: expected that X highest bit is set, got 0x1
input.c:4549: Test failed: 8:2: expected that X keystate is set
input.c:4549: Test failed: 8:2: expected that X keystate is set
input.c:4556: Test failed: 8:2: expected that X keystate is set
input.c:4556: Test failed: 8:2: expected that X keystate is set
input.c:4548: Test failed: 8:3: expected that X highest bit is set, got 0
input.c:4549: Test failed: 8:3: expected that X keystate is set
input.c:4549: Test failed: 8:3: expected that X keystate is set
input.c:4556: Test failed: 8:3: expected that X keystate is set
input.c:4556: Test failed: 8:3: expected that X keystate is set

=== debian11 (32 bit zh:CN report) ===

user32:
input.c:555: Test failed: peek: lmenu_vkey_peeked: 1: 2: got msg WM_SYSCHAR, wparam 0x66, lparam 0x20020001
input.c:555: Test failed: peek: shift_vkey: 1: 2: got msg WM_CHAR, wparam 0x46, lparam 0x20001
input.c:555: Test failed: receive: lmenu_vkey: 1: 2: got msg WM_SYSCHAR, wparam 0x66, lparam 0x20020001
input.c:555: Test failed: receive: lmenu_vkey: 1: 3: got msg WM_SYSCOMMAND, wparam 0xf100, lparam 0x66
input.c:555: Test failed: receive: shift_vkey: 1: 2: got msg WM_CHAR, wparam 0x46, lparam 0x20001

[Rémi Bernon (＠rbernon)]

Rémi Bernon (@rbernon) commented about dlls/win32u/input.c:
>  /*
>   * Microsoft Office expects this value to be something specific
>   * for Japanese and Korean Windows with an IME the value is 0xe001
>   * We should probably check to see if an IME exists and if so then
>   * set this word properly.
> -
> *
> -
> * On Vista+, the high word is always layout, not 0xe00* even when IME is on.
> -
> * Super Robo Wars 30 (SteamID: 898750) depends on it.
> */
> - if (NtCurrentTeb()->Peb->OSMajorVersion <= 5)
> - {
>     langid = PRIMARYLANGID( LANGIDFROMLCID( layout ) );
>     if (langid == LANG_CHINESE || langid == LANG_JAPANESE || langid == LANG_KOREAN)
>         layout = MAKELONG( layout, 0xe001 ); /* IME */
> - else

I'm not sure we need to keep this tbh. The 0xe001 high bits is simply very likely coming from imm32, and whatever Office was doing, if that's truly the case, will simply not work anymore in any recent Windows version.