-----Original Message-----
From: Brodie Thiesfield [mailto:[EMAIL PROTECTED]
Sent: Sunday, December 17, 2006 10:10 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] building sqlite on windows in Unicode
[EMAIL PROTECTED] wrote:
Brodie Thiesfield <[EMAIL PROTECTED]> wrote:
Done. Is there anything else that is necessary to contribute code
and
patches to sqlite?
For ticket #2023, the first patch seems unlikely to work right
since it changes the character encoding for LoadLibrary() but
leaves it unchanged for FreeLibrary(). That seems wrong to me,
but not having any access to WinCE (and having zero desire to
ever get access) I have no way of testing it.
I didn't write the first patch. It should just be ignored as my patch
is
more comprehensive.
The only function that has a different version for UNICODE vs MBCS is
LoadLibrary (i.e. both LoadLibraryA and LoadLibraryW). This can be seen
from the documentation. The T in LPCTSTR in the LoadLibrary definition
signifies that there is both A and W versions. GetProcAddress takes
only
a LPCSTR which is always char*. FreeLibrary takes only the handle to
the
library that LoadLibrary created.
These functions are pretty much the same as dlopen/dlsym/dlclose, with
the exception that LoadLibrary needs to be specially handled.
MSDN documentation:
LoadLibrary http://snipurl.com/loadlibrary
GetProcAddress http://snipurl.com/getprocaddress
FreeLibrary http://snipurl.com/freelibrary
The second patch extends the OS interface in ways that will break
legacy implementations. A significant part of my income derives
from people and companies who pay me to not do that.
If those implementations are not be broken by the current
implementation
of loadext.c then surely these changes won't break them either. The
whole idea of have the OS interface is that it abstracts the OS away in
a single location. Hacking OS abstraction into other parts of the
codebase (e.g. the current loadext.c) is not the correct thing to do.
In
any case, since all of those people/companies are either supported by
the current method of dlopen/sym/close as is currently used in
loadext.c, or they aren't using 3.3.7+
I could perhaps fix up either patch to do the right thing, but
then I would have no way of testing the results, since I do not
have access to WinCE.
You do not need access to WinCE. It also breaks the build on Windows
when defining _UNICODE. I'm sure that you an set the _UNICODE define
(removing _MBCS) on your cross-compiler (if that is what you are
using).
If you can you elaborate more on the requirements for changes to the OS
layer then I can adapt my patch to fit your requirements.
The above are some of the reasons that there has been so little
movement on ticket #2023.
Your contributions are greatly appreciated. Please do not let
anything I say or do discourage you from contributing again to
either SQLite or other open source projects. User contributions
are very important to open source projects like SQLite and I want
to encourage them. But you also need to understand that there is
no guarantee that a patch will be accepted. With SQLite in
particular, with me in the drivers seat, it is very very difficult
to get a patch accepted into the core. It has been done, but it
does not happen very often. Usually, if I implement a suggested
feature at all, I merely use the patch as a guideline to implement
my own changes. Do not let this discourage you. Your patch has
been recorded in the bug tracking system, and I have studied it
closely. It will be likely used as a reference someday. Just
not today.
Having these comments added to the bug system would be useful to start
with. You have your reasons for ignoring the bug, but with no movement
at all it is frustrating to have to continually patch the source just
to
get it to build on Windows. Especially when it is so simple to get it
to
work.
Regards,
Brodie
-----------------------------------------------------------------------
------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------
------
