[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@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?
--