> -----Original Message-----
> From: Brodie Thiesfield [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 20, 2006 4:43 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Need a wince test
>
> Robert Simpson wrote:
> >> From: Brodie Thiesfield [mailto:[EMAIL PROTECTED]
> >> Robert, you are missing the point. Because of the way this is being
> >> defined, there is a need to check for _UNICODE. If you don't then a
> >> build with _UNICODE defined will fail. If it was implemented like
> the
> >> rest of the functions in os_win.c then it wouldn't be necessary.
> >
> > I can go either way on that. There is no need to check for _UNICODE
> if you
> > change the defines ... to this:
> >
> > # ifdef _WIN32_WCE
> > //snip
> > # else
> > # define SQLITE_OPEN_LIBRARY(A) LoadLibraryA(A) // <-- changed to
> A
> > # define SQLITE_FIND_SYMBOL(A,B) GetProcAddress(A,B)
> > # endif
>
> That way you are ensuring that non-ASCII strings won't work on any
> platform other than WINCE. It's the worse solution so far. Why do you
> have such a problem accepting the _UNICODE define? I feel like I am
> arguing with a brick wall.
I don't have a problem with the _UNICODE define, I have a problem with the
differences in support between CE and the desktop.
> The following patch is a version of drh's that will compile and work on
> in the cases that you and I want (e.g. Unicode build). See my original
> reply to drh as to why it is better than his (although see below for
> why
> it is still bad).
>
> # ifdef _UNICODE // hey, look, we catch _WIN_WCE here too!
> static HANDLE loadLibraryUtf8(const char *z){
> WCHAR zWide[MAX_PATH];
> DWORD dwLen = MultiByteToWideChar(CP_UTF8,0,z,-1,zWide,MAX_PATH);
> if (dwLen == 0 || dwLen > MAX_PATH) return NULL;
> return LoadLibraryW(zWide);
> }
> # define SQLITE_OPEN_LIBRARY(A) loadLibraryUtf8(A)
> # else
> # define SQLITE_OPEN_LIBRARY(A) LoadLibraryA(A)
> # endif
> # define SQLITE_FIND_SYMBOL(A,B) GetProcAddress(A,B)
>
> If _UNICODE is defined it works fine. When _UNICODE is not defined (the
> default) it has UTF-8/ANSI coding problems on *all* platforms (unlike
> os_win functions which have them only on Win9x).
CP_UTF8 doesn't work on most CE platforms and hence your proposed patch
doesn't work.
> This is why at a minimum it needs to be included in os_win.c and
> implemented like all other functions there. As per my original patch on
> the bug report. Can we just implement it there, export it from there
> and
> use it in loadext.c without touching the os.h header that drh seems so
> allergic to?
>
[snip diagram]
>
> > Here's what I propose ...
> > #ifdef _UNICODE
> > #define OSSTR wchar_t
> > #else
> > #define OSSTR char
> >
> > OSSTR *utf8toOS(char *utf8)
> > void utf8toOSFree(OSSTR *apiString)
>
> Although it is nice since it is simple, it is worse than the current
> solution. Firstly, with the current method, only Windows 95 is broken.
> Additionally, the current solution has the nice property of using the
> unicode functions whenever available (i.e. when running on WinNT)
> regardless of build type.
>
> Your proposal takes a step backwards to providing Unicode support only
> when compiled as a Unicode application. It is better to continue the
> current method of calling W functions where possible and falling back
> to
> A only when necessary, just process the string sent into the A function
> so that it is properly ACP/OEM as necessary.
I'm not sure what you're getting all worked up over. How is "providing
unicode support only when compiled as a unicode application" a Bad Thing?
99.9% of all API calls that take a string have an A and W version defined.
The LoadLibrary() function maps to LoadLibraryW when _UNICODE is defined,
and LoadLibraryA() when _UNICODE is not defined. What's so wrong with this
system? Why is it so terrible to convert a utf8 string to MBCS and call an
A function when _UNICODE isn't defined, and to convert a utf8 string to
unicode and call the W function when _UNICODE *is* defined?
Robert
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
