http://bugs.winehq.org/show_bug.cgi?id=35009 --- Comment #7 from Anastasius Focht <focht(a)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 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.