http://bugs.winehq.org/show_bug.cgi?id=35009
--- Comment #7 from Anastasius Focht focht@gmx.net 2013-12-03 16:23:13 CST --- Hello folks,
I think this is another case of incompatibility between Wine's use of unicode.org and Microsoft collation tables.
The culprit is a string array lookup/comparison loop where the app uses lstrcmpiA() which of doesn't work correctly for Wine if you pass in japanese character strings.
string2 (argument on stack, passed in):
--- snip --- Address Hex dump ASCII 0033FA90 43 48 52 5F|96 B2 5F 97|63 8F AD 00|00 00 00 00| CHR_–²_—c --- snip ---
It tries the following string1 values before giving up (I just cut the hexdump at the NULL terminator):
--- snip --- Address Hex dump ASCII 00640341 43 48 52 5F|90 E7 94 67|5F 8A EC 5F|83 70 83 57| CHR_ç”g_Šì_ƒpƒW 00640351 83 83 83 7D|4C 5F 95 5C|8F EE 00 ƒƒƒ}L_•\î --- snip ---
--- snip --- Address Hex dump ASCII 00640C0B 43 48 52 5F|91 8D 88 EA|98 4E 5F 8A|EE 5F 83 47| CHR_‘ˆê˜N_Šî_ƒG 00640C1B 83 76 83 8D|83 93 00 ƒvƒƒ“ --- snip ---
--- snip --- Address Hex dump ASCII 00640643 43 48 52 5F|90 E7 94 67|5F 8A EE 5F|89 C4 8E 84| CHR_ç”g_Šî_‰ÄŽ„ 00640653 95 9E 5F 90|81 8F 6F 52|5F 95 5C 8F|EE 00 •ž_oR_•\î --- snip ---
--- snip --- Address Hex dump ASCII 00640735 43 48 52 5F|90 E7 94 67|5F 94 DF 5F|83 70 83 57| CHR_ç”g_”ß_ƒpƒW 00640745 83 83 83 7D|5F 95 5C 8F|EE 00 ƒƒƒ}_•\î --- snip ---
--- snip --- Address Hex dump ASCII 006407A8 43 48 52 5F|90 E7 94 67|5F 94 DF 5F|89 C4 8E 84| CHR_ç”g_”ß_‰ÄŽ„ 006407B8 95 9E 5F 90|81 8F 6F 4C|5F 95 5C 8F|EE 00 •ž_oL_•\î --- snip ---
--- snip --- Address Hex dump ASCII 006407FD 43 48 52 5F|90 E7 94 67|5F 94 DF 5F|89 C4 8E 84| CHR_ç”g_”ß_‰ÄŽ„ 0064080D 95 9E 5F 95|5C 8F EE 00| •ž_•\î --- snip ---
--- snip --- Address Hex dump ASCII 00640762 43 48 52 5F|90 E7 94 67|5F 94 DF 5F|89 C4 8E 84| CHR_ç”g_”ß_‰ÄŽ„ 00640772 95 9E 4C 00| •žL --- snip ---
--- snip --- Address Hex dump ASCII 00640776 43 48 52 5F|90 E7 94 67|5F 94 DF 5F|89 C4 8E 84| CHR_ç”g_”ß_‰ÄŽ„ 00640786 95 9E 4C 5F|95 5C 8F EE|00 •žL_•\î --- snip ---
If the comparison results in equality (=0) it bails out to a code path which indicates "found" to caller. If the comparison returns >= it tweaks the lookup to search another array range.
(0x90,0x96) = -1 (0x91,0x96) = 1 (0x90,0x96) = -1 ...
Not sure why the authors chose to use lstrcmpiA() when even MSDN states:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms647489%28v=vs.85%2...
--- quote --- For some locales, the lstrcmpi function may be insufficient. If this occurs, use CompareString to ensure proper comparison. For example, in Japan call with the NORM_IGNORECASE, NORM_IGNOREKANATYPE, and NORM_IGNOREWIDTH values to achieve the most appropriate non-exact string comparison. The NORM_IGNOREKANATYPE and NORM_IGNOREWIDTH values are ignored in non-Asian locales, so you can set these values for all locales and be guaranteed to have a culturally correct "insensitive" sorting regardless of the locale. Note that specifying these values slows performance, so use them only when necessary. --- quote ---
If you want to debug it: the loop starts at 0x0043CD55, lstrcmpiA() at 0x0043CD7E.
So you might hook to one of the already existing lstrcmpi/CompareStringA/W bugs.
Regards