> -----Original Message-----
> From: Brodie Thiesfield [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 19, 2006 9:17 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Need a wince test
> 
> There are a few problems with your patch.
> 
> +# ifdef _WIN32_WCE
> +    static HANDLE loadLibraryUtf8(const char *z){
> +      WCHAR zWide[MAX_PATH];
> +      MultiByteToWideChar(CP_ACP,0,z,-1,zWide,MAX_PATH);
> +      return LoadLibrary(zWide);
> +    }
> +#   define SQLITE_OPEN_LIBRARY(A)  loadLibraryUtf8(A)
> +#   define SQLITE_FIND_SYMBOL(A,B) GetProcAddressA(A,B)
> +# else
> +#   define SQLITE_OPEN_LIBRARY(A)  LoadLibrary(A)
> +#   define SQLITE_FIND_SYMBOL(A,B) GetProcAddress(A,B)
> +# endif
> 
> The problem in question is not a Windows CE only one. It occurs with
> any
> client that builds in Unicode mode. Therefore you need to test for the
> _UNICODE define instead of _WINCE. Windows CE compilers will also set
> _UNICODE (I believe - Robert?).
> 
> CP_ACP is not UTF-8. Use either CP_UTF8 or your own UTF-8 conversion
> functions from the OS library. Note also that MultiByteToWideChar may
> fail or return ERROR_NO_UNICODE_TRANSLATION (1113L) for UTF-8
> conversions.
> 
> There is no GetProcAddressA. You need to use GetProcAddress.
> 
> The patch will need to be something like the following. Which I have
> tested and builds with no errors or warnings in _UNICODE mode. Still
> need someone to test it in WINCE to be sure.

There's some flaws in your arguments, Brodie ...

1.  There's no need to do this whole _UNICODE test, only the _WINCE test is
needed.  All versions of Windows that support unicode also support the ANSI
versions of the API calls -- the only Windows platform that doesn't have any
ANSI support is Windows CE.  A single one-character modification to DRH's
proposed patch is all that's needed for regular Windows desktop support.

2.  You're ignoring that the ANSI versions that already exist in loadext.c
are potentially passing a utf8 char * to LoadLibraryA() right now and have
been since loadext.c was created.  If you really want to be technical about
it, all the strings passed to LoadLibrary() and GetProcAddress() need to be
converted from utf8 to MBCS for non-CE platforms.

There are two possible solutions, and these are the same issues we've had in
os_win ...

1.  Bite the bullet and realize that Windows API calls are natively MBCS,
not utf8, and convert any char * from utf8 to mbcs before passing them to a
Windows API call.

2.  Just assume that certain functions for Windows are going to take an mbcs
string instead of a utf8 string, like sqlite3_open() and
sqlite3_load_extension()


DRH, your proposed patch almost works with _UNICODE defined.  Just change it
to this instead (my changes are marked with -->):

--- loadext.c   2006/09/22 23:38:21     1.14
+++ loadext.c   2006/12/20 03:37:35     1.15
@@ -223,8 +223,18 @@
 #if defined(_WIN32) || defined(WIN32) || defined(__MINGW32__) ||
defined(__BORLANDC__)
 # include <windows.h>
 # define SQLITE_LIBRARY_TYPE     HANDLE
-# define SQLITE_OPEN_LIBRARY(A)  LoadLibrary(A)
-# define SQLITE_FIND_SYMBOL(A,B) GetProcAddress(A,B)
+# ifdef _WIN32_WCE
+    static HANDLE loadLibraryUtf8(const char *z){
+      WCHAR zWide[MAX_PATH];
+      MultiByteToWideChar(CP_ACP,0,z,-1,zWide,MAX_PATH);
+      return LoadLibrary(zWide);
+    }
+#   define SQLITE_OPEN_LIBRARY(A)  loadLibraryUtf8(A)
--> +#   define SQLITE_FIND_SYMBOL(A,B) GetProcAddress(A,B)
+# else
--> +#   define SQLITE_OPEN_LIBRARY(A)  LoadLibraryA(A)
+#   define SQLITE_FIND_SYMBOL(A,B) GetProcAddress(A,B)
+# endif
 # define SQLITE_CLOSE_LIBRARY(A) FreeLibrary(A)
 #endif /* windows */
 
Unfortunately the larger issue still remains, that all ANSI api calls in
Windows expect MBCS strings and not utf8 strings.  Technically what you
should do is have two functions:

loadLibraryUtf16() for WINCE that converts the utf8 string to utf16/unicode
and calls LoadLibraryW()
loadLibraryUtf8() for the rest of Windows, which converts a utf8 string to
mbcs and calls LoadLibraryA()

Robert




-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------

Reply via email to