Shachar Shemesh wrote:
Dmitry Timoshkov wrote:
"Mike McCormack" mike@codeweavers.com wrote:
The flag (0x10000000) passed to CompareString reverse the sort order of a number of unicode characters. I've got no idea why it would want to do that... maybe somebody can shed some light on what the reason behind this would be?
Attached is a small test case that demonstrates a problem in Wine's compare string. Explanation: The word "Mohammad" is spelled in Arabic Meem, Hah, Meem, Shadda, Dal. The Shadda's purpose is to double the pronunciation of the preceding letter, which is the reason it's written with a double M in English. The attached program uses "CompareStringW" to compare the proper spelling of "Mohammad" to three variations. One is the version without the Shadda at all (as Mohammad is usually spelled by modern Arabic writers), one is Mohammad with the Meem explicitly doubled, and one is the same as the last one, where the second Meem is replaced with the preceding letter (Lam). They are noted as "mohamad", "mohammad" and "mohamlad" respectively. The one with proper spelling is noted as "moham_ad".
moham_ad is compared against all three with no flags, with the "NORM_IGNORENONSPACE" flag, and with our unidentified flag. The program was run on Windows 2000 and on Wine.
On W2K, moham_ad is sorted between mohamlad and mohammad. If IGNORENONSPACE is used, it is exactly equal to mohammad. One wine, moham_ad is less than all three. This means we have a bug in Wine.
Shachar