Robert, does the patch I provided work as is on Windows CE or not?
Robert Simpson wrote:
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.
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.
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.
As far as I understand, sqlite changed sometime in the early 3.0
versions such that char* strings (input and output) are always assumed
to be UTF-8.
See:
http://www.sqlite.org/cvstrac/tktview?tn=1695
http://www.sqlite.org/cvstrac/tktview?tn=1533
If these strings are passed directly into win32 ansi functions then that
is a different bug and one that needs to be fixed. It is not part of
this bug. This patch would also need to be fixed too.
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.
Given the current API documentation and what has been written in the bug
referenced earlier, this seems the only possibility.
DRH, your proposed patch almost works with _UNICODE defined. Just change it
to this instead (my changes are marked with -->):
No, it doesn't. It needs to have the define check changed to _UNICODE
instead of _WIN32_WCE (which will still support CE). It also needs error
checking of the conversion. It needs to call the correct functions.
Ideally it should be implemented like the rest of the functions in os_win.c
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()
Yes. But this is a separate problem. Look at the code in os_win.c, e.g.
sqlite3WinFileExists. On Windows NT platforms, it will work fine only if
the caller supplies a ASCII or UTF-8 string (CP_ACP encoded strings will
fail). On Windows 9x platforms it will work fine only if the caller
supplies an ASCII or CP_ACP string (UTF-8 encoded strings will fail).
Probably most users on Win9x are still passing in ANSI strings which is
why it is working. Change it to actually match the documentation and you
will probably see a few more failures.
Brodie
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
