I wrote the original patch to loadext.c with the intent of making it as minimally obtrusive as possible to the existing code structure. I know firsthand how much DRH hates changing his codebase :)
As Brodie stated, FreeLibrary() takes a type HANDLE, which is returned from a call to LoadLibrary() -- so the only time the string needs referencing is at the original LoadLibrary() call. FWIW, that patch I wrote is currently in production code in the ADO.NET 2.0 provider and in use by Windows CE users since October. Robert > -----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] > ----------------------------------------------------------------------- > ------ ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
