I'm using SQlite as source too, and every time I pull the source I rewrite os.c to accomodate it to my UNICODE app, namely I replace all ambiguous file-handling APIs into their ASCII versions. Then I convert filename into ASCII in my app, then pass it to SQLite. But as you know it's far better if direct passing of wide char filename is possible, and it should be possible since only os.c handle files with their real names and the rest operates with handle.
I submit http://www.sqlite.org/cvstrac/tktview?tn=239 8 months ago but got so little feedback I found there's very little number of people who concern about UNICODE (UTF-16) among users of SQLite. (Also please refer to Message-Id: <[EMAIL PROTECTED]> of this list) For me I choose SQLite for its performance therefore I'm strongly against implicit WideCharToMultiByte inclusion in SQLite. I rather like to see MS-Windows-style interface definition like: #ifdef UNICODE #define sqlite_open sqlite_openW #else #define sqlite_open sqlite_openA #endif in sqlite.h, and corresponding WIDE/ASCII versions of functions in os.c, or binary object file of SQLite. It's the standard MS-Windows-way, at least. To preserve binary compatibility and old sqlite_open intact, #ifdef UNICODE #define sqlite_open sqlite_openW #endif may be better. -- KL On Fri, 21 Nov 2003 16:23:31 -0600 "Rob Fowler" <[EMAIL PROTECTED]> wrote: > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
