[rfc] lstrcmpi: order still wrong (was "Re: Regression in lstrcmpiA (occurred in late June, NLS related)" from 2003 year)
Hello! Previous thread on this topic: http://www.mail-archive.com/wine-devel@winehq.org/msg01080.html I've stumbled over problem with lstrcmpi sorting is still wrong. Some japanese game engine uses binary search on presorted array, and fails with a-la "object not found" errors. Judging by object order in archive, === cut === ... conf_p.MGD----- (would fail with strcasecmp, ok with wine) conf01.MGD--/ ... title.MGD------ fails with vanilla wine title_p.MGD--/ ... === cut === proper order should be "_" < "0" (ok) and "." < "_" (fails with vanilla wine). I've replaced collation weight of '_' with 0x02560111, and now these games run fine; but that's dirty hack, of cause, and should not be applied to upstream: 1) it is modifies generated file; 2) weight for "_" chosen arbitrary and can cause conflicts somewhere else (or, rather, not can, but certainly will - there are other symbols with weight 0x0256???); 3) weight for other "_"-like chars should be modified too. Hope you can suggest better solution. FWIW, I've checked mentioned in previous thread unicode-2.1.9d8 tables - same mismatch, will not work too. I think, only proper way is somehow extract this table from windows (either directly by LCMapStringW(LC_MAP_SORTKEY), or sorting array of a[i]=i; with CompareStringW and using that order). I'm not a lawyer, but really doubt that such reproduced table can be considered copyrightable anywhere. How can anyone make compatible reimplementation without reproducing in some way this table?
Yuriy Kaminskiy wrote:
I've stumbled over problem with lstrcmpi sorting is still wrong. Some japanese game engine uses binary search on presorted array, and fails with a-la "object not found" errors.
[...]
proper order should be "_" < "0" (ok) and "." < "_" (fails with vanilla wine).
Well, after private email, I think I should stress out, that while I /believe/ that sort order in winxp does not depend on locale, it is also /possible/ that I'm wrong - I don't have working windows installation at hands and cannot check that. [Nevertheless, I've ran that game in japanese locale [ja_JP.UTF-8], and /if/ sort order in winxp depend on locale, sort order in wine should be fixed to depend on locale too: still bug, but slightly different ;-)].
On 04.07.2009 23:55, Yuriy Kaminskiy wrote:
Yuriy Kaminskiy wrote: I'm wrong - I don't have working windows installation at hands and cannot check that.
Well, no answer so far; I thought "should write test, code is more welcomed than just words", and noticed that such test already present, but disabled :-E. That's wrong. If test report breakage, it should not be simply silenced and forgotten for 6 years. See "[rfc] [kernel32/tests] enable sort order test" series in *-patches
"Yuriy Kaminskiy" yumkam@mail.ru wrote:
Well, no answer so far; I thought "should write test, code is more welcomed than just words", and noticed that such test already present, but disabled :-E. That's wrong. If test report breakage, it should not be simply silenced and forgotten for 6 years. See "[rfc] [kernel32/tests] enable sort order test" series in *-patches
It's been explained before the source of the problem (incompatibility between unicode.org and microsoft collation tables), and a possible way to solve it (patch the generated tables in the parsing script).
-
Dmitry Timoshkov -
Yuriy Kaminskiy