https://bugs.winehq.org/show_bug.cgi?id=54669
Bug ID: 54669 Summary: imm32:imm32 - ime_install() fails on on Windows in mixed locales Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: imm32 Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com
imm32:imm32 - ime_install() fails on on Windows in mixed locales:
imm32.c:2614: Test failed: unexpected call IME_DLL_PROCESS_DETACH imm32.c:2782: Test failed: ImmLoadIME returned 0 imm32.c:2790: Test failed: ImmLoadIME returned 0 imm32.c:2798: Test failed: expected ImeDestroy imm32.c:2614: Test failed: unexpected call IME_DLL_PROCESS_DETACH imm32.c:2816: Test failed: ImmLoadIME returned 0 imm32.c:2824: Test failed: ImmLoadIME returned 0 imm32.c:2832: Test failed: expected ImeDestroy
See https://test.winehq.org/data/patterns.html#imm32:imm32
The failures started with the commit below:
commit 05cf38bfa63980af7a094b1c087bee4ea36eb485 Author: Rémi Bernon rbernon@codeweavers.com AuthorDate: Mon Mar 6 19:19:06 2023 +0100
imm32/tests: Test undocumented ImmLoadIME / ImmFreeLayout.
https://bugs.winehq.org/show_bug.cgi?id=54669
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression, source, | |testcase Regression SHA1| |05cf38bfa63980af7a094b1c087 | |bee4ea36eb485
https://bugs.winehq.org/show_bug.cgi?id=54669
François Gouget fgouget@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|imm32:imm32 - ime_install() |imm32:imm32 - ime_install() |fails on on Windows in |fails in some locales on |mixed locales |Windows
--- Comment #1 from François Gouget fgouget@codeweavers.com --- This set of failures is not specific to the mixed locales test configuration, it just seems to be systematic there. But this also happened on the w10pro64-en-AE-u8. Time will tell if it happens in other locales too...
https://bugs.winehq.org/show_bug.cgi?id=54669
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon@codeweavers.com
--- Comment #2 from Rémi Bernon rbernon@codeweavers.com --- At least for the mixed locale setup I think the issue is fixed now. The problem was that the IME is declaring to support a specific language, and if that locale isn't available in the system the IME will fail to load.
I used LANG_NEUTRAL language initially as it seemed to be working everywhere, but apparently not on this setup, and I've changed it to LANG_INVARIANT, whatever that means it seems to be working even better.
https://bugs.winehq.org/show_bug.cgi?id=54669
Rémi Bernon rbernon@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Fixed by SHA1| |7f5007f19737449a147d7c4ae35 | |6a515df264854 Resolution|--- |FIXED
--- Comment #3 from Rémi Bernon rbernon@codeweavers.com --- Marking as fixed with 7f5007f19737449a147d7c4ae356a515df264854
https://bugs.winehq.org/show_bug.cgi?id=54669
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #4 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 8.4.
https://bugs.winehq.org/show_bug.cgi?id=54669
--- Comment #5 from François Gouget fgouget@codeweavers.com --- The way I see this, LANG_INVARIANT is to Windows what LANG=C is to Unix, i.e. it's for when you want the result to not depend on the user's locale settings. See LOCALE_INVARIANT for Microsoft's documentation.
For resources LANG_NEUTRAL + SUBLANG_NEUTRAL identifies resources that don't need to be translated (such as icons, mouse pointers, etc.) and thus can be used in any locale. But in other contexts (such was when passed to StringFormat()), it seems to mean to use the user's default language. But I find that aspect to not be very clear.
Since here the LANGID is applied to a resource it's strange that it is LANG_INVARIANT that works. But maybe it's because that resource is essentially code so it's the API rules that apply.
Anyway, it works now.