> -----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] -----------------------------------------------------------------------------