Thanks for the insight, Arthur. I guess since you're using Sqlite as a DLL, you *could* switch on UNICODE within your own app, although I understand why you don't. I'm using the Sqlite source files within my app directly. I switch on UNICODE so that the rest of my app (outside of Sqlite) can use the wide versions of the Win32 functions on NT/2000/XP. The wide versions are faster because of the native use of Unicode on those platforms. I choose to let the older 95/98/Me machines take a performance hit by using the Microsoft Layer for Unicode, so I don't have to support two versions of my app.
-----Original Message----- From: Arthur Hsu [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 4:04 PM To: [EMAIL PROTECTED] Subject: Re: [sqlite] Win32 coders: change os.c? Importance: Low Here's my flow of using sqlite. I build sqlite *without* using turn the Unicode support on and use it as DLL. So, when I use it in VC++, I can do user input UTF-16 WideCharToMultiByte (wchar_t -> char) sqlite_function Win32FunctionA() MultiByteToWideChar (char -> wchar_t) data that my app can use Actually it's not necessary to use Unicode in order to achieve i18n under Windows development environment. I still prefer using MBCS. For example, my program supports Chinese Simplified (GB2312), Chinese Traditional (BIG5), Japanese (Shift-JIS) and English (Windows 1252). By storing the string resources inside sqlite database without Unicode turned on, corresponding contents can be displayed perfectly in localized versions of Windows 98, Me, 2000 and XP, also the XP with MUI pack. Thus I don't need to build an extra resource DLL/assembly for each culture. -Arthur --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
