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