[rfc] lstrcmpi: order still wrong (was "Re: Regression in lstrcmpiA (occurred in late June, NLS related)" from 2003 year)

[Yuriy Kaminskiy]

Hello!
   Previous thread on this topic:
http://www.mail-archive.com/wine-devel(a)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?
--

[rfc] lstrcmpi: order still wrong (was "Re: Regression in lstrcmpiA (occurred in late June, NLS related)" from 2003 year)

[Yuriy Kaminskiy]

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)

[Yuriy Kaminskiy]

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

[rfc] lstrcmpi: order still wrong (was "Re: Regression inlstrcmpiA (occurred in late June, NLS related)" from 2003 year)

[Dmitry Timoshkov]

"Yuriy Kaminskiy" <yumkam(a)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.