KL, thanks. I'm glad to hear someone in agreement with me that using
WideCharToMultiByte within os.c is not preferable for performance reasons.
>From what I gather, you're doing the exact same thing I'm doing: changing
all the string handling Win32 functions in os.c to their 'A' versions. I
*love* your idea of handling wide char filenames natively like this:
#ifdef UNICODE
#define sqlite_open sqlite_openW
#else
#define sqlite_open sqlite_openA
#endif
Have you implemented those functions, or is it just an idea? If you've
implemented it, would you be willing to share your code?
Cheers,
Rob
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Friday, November 21, 2003 8:33 PM
To: [EMAIL PROTECTED]
Subject: Re: [sqlite] Win32 coders: change os.c?
Importance: Low
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
