http://bugs.winehq.org/show_bug.cgi?id=34176
--- Comment #5 from Emmanuel Jacobs wine.manette@manette.be 2013-08-02 11:18:59 CDT --- (In reply to comment #4)
Is this related to bug 9583 and/or bug 10767?
Sure for bug 9583 (altough behavior described there impact the same function it is not the same effect, I'm complaining about equality of that function, they are complaining about < or > aka sorting).
I see in wine source code (http://source.winehq.org/source/dlls/kernel32/locale.c#L2913) tahat CompareStringW is calling CompareStringEx (http://source.winehq.org/source/dlls/kernel32/locale.c#L2922) wihich in turn is calling wine_compare_string (http://source.winehq.org/source/libs/wine/sortkey.c#L333).
Locale is not "forwarded" from ...W to ...Ex so IMHO this should not be a locale configuration problem (but maybe locale is checked in that very last function ?)
Given the second parameters (0x1) passed from the program (both when executed from Windows as well as from Wine) to the CompareStringW call is NORM_IGNORECASE(http://source.winehq.org/source/include/winnls.h#L345) the question is should é be = to e, ² be = to 2 and 3 be = to ³ from the unicode standard point of view ? COuld we tell Wine to behave like Windows for this matter ?
Maybe we can have the point of view of Dmitry Timoshkov which seems to have introduced the code into Wine ?