Since you are modifying the win32 side of the unicode tables please add the correponding tests for LCMapString() to dlls/kernel32/tests/locale.c. It's quite possible that msvcrt doesn't use a win32 backend and has its own locale support.
I could imagine LCMAP_LINGUISTIC_CASING making a difference here.
Windows' LCMapString behaves differently but only if LCMAP_LINGUISTIC_CASING is specified. if that flag is not specified, it works just like tolower/toupper
Wine's LCMapString currently calls tolowerW and doesn't support the LCMAP_LINGUISTIC_CASING flag. But the current table contains the conversions the LCMAP_LINGUISTIC_CASING flag needs if added in the future
Should I change the fix to something like one of the following? Or just add tests with todo_wine for now?
I could have msvcrt tolower call LCMapString(LOWERCASE)? Then: - LCMapString(LOWERCASE|CASING) calls the current tolowerW with the conversion - LCMapString(LOWER) calls tolowerW except on certain characters (like Turkish i) - msvcrt tolower variants call LCMapString(LOWER)
Or alternatively could there be new tolowerW function that doesn't do the conversion (maybe from a second table make_unicode produces)? Then: - LCMapString(LOWERCASE|CASING) call the current tolowerW with the conversion - LCMapString(LOWERCASE) and msvcrt tolower variants call new tolowerW without the conversion
This patch was for the Turkish I but I have 1 other character with the same issue and I'm sure there are more
Thanks daniel