1. You are still passing UTF-8 strings to Win95/98/ME file. No Windows version (not Win95 nor NT) accepts UTF-8 strings, especially not those ending with ...A and ...W.
The only functions taking any other codepages are a few functions which especially deal with strings and codepage conversions. 2. CP_UTF8 might not be available on all systems. The WideCharToMultiByte help states that the codepage must be installed on the system. I might be mistaken, but apparently CP_UTF8 was not available on early Win95, that's why most Windows apps provide their own UTF8 encoding / decoding. Why not use the native SQLite conversions already available in utf8.c? 3. The ...W functions require strings as UTF-16-LE. Applies to NT and later. 4. The ...A functions require ANSI strings in the user's codepage. Since you can not convert UTF-8 to user directly, you need to convert to UTF-16-LE first. Then convert to the ANSI user codepage with WideCharToMultiByte. Applies to 95/98/ME. To sum up: You need to convert UTF-8 to UTF-16-LE first. Then, if the OS is NT, you can pass these to the ...W functions. Otherwise, you need to further convert to ANSI user codepage and pass it to the ...A functions. There might be problems if the user's codepage does not cover all code points originally contained in the UTF-8 string and some characters might fall back, like from 'ä' to 'a', if 'ä' is unsupported. You might flat this as an error, but for file access it should not matter a great deal since all file dialogs etc. are ANSI as well. Regards, Ralf >Can somebody with access to Win95/98/ME please test >check-in [2656] for me to make sure it didn't break >anything? > >http://www.sqlite.org/cvstrac/chngview?cn=2656
