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.
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).
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?
This is so simple. I'll draw a diagram.
If you want...
-> full support on WinNT/WinCE when built in _UNICODE,
broken when using non-ASCII chars at all other times?
== Implement as above.
-> full support on WinNT/WinCE regardless of build type,
broken when using non-ASCII chars on Win9x?
== Implement like all other functions in os_win,
export from there, use in load_ext.c
-> full support on all platforms regardless of build type
== Implement like all other functions in os_win,
export from there, use in load_ext.c
+ fix all functions in os_win to work on Win9x
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.
Brodie
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
