Re: [rfc] lstrcmpi: order still wrong (was "Re: Regression in lstrcmpiA (occurred in late June, NLS related)" from 2003 year)
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
Re: [rfc] lstrcmpi: order still wrong (was "Re: Regression in lstrcmpiA (occurred in late June, NLS related)" from 2003 year)
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 ;-)].
[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? --
