RE: [sqlite] building sqlite on windows in Unicode
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] -
Re: [sqlite] building sqlite on windows in Unicode
Robert Simpson wrote: 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 :) [snip] 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. I don't doubt that your patch fixes your specific problem, however it has 2 main problems for me: 1) it doesn't address the larger problem of building the library in UNICODE mode in general (of which Windows CE is just one client) 2) you've assumed that the char* strings are in CP_ACP whereas I understand that all char* are UTF-8. That said I can easily write a patch that doesn't touch the OS abstraction code, it just seems crazy to hack missing OS abstraction functions into files all around the codebase just in order to avoid adding them to the existing OS abstraction layer. Regards, Brodie -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
Re: [sqlite] building sqlite on windows in Unicode
Many large open source projects have committers for specific platforms, or particular sections of the code. I would think that Windows support and autoconfigury would be good candidates for delegation. One guy can't do it all. --- Brodie Thiesfield [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] wrote: 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. __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] building sqlite on windows in Unicode
Done. Is there anything else that is necessary to contribute code and patches to sqlite? The bug database seems to lack feedback (many bugs seem to just lie stale, there is no way to create an account to login, etc). I can't find documentation on the website on contributions. Regards, Brodie Christian Smith wrote: Check the requirements in: http://www.sqlite.org/copyright.html for patches and other submissions to SQLite. This could be what is holding up inclusion of the patch. Christian Brodie Thiesfield uttered: Hi, Building sqlite on windows in Unicode mode broke with the addition of the loadable extensions. I found a bug matching this problem and attached a patch to it to fix it a while ago, however I haven't seen any other comments or movement in the bug. I'm not sure what else needs to be done to have a patch accepted, so I'm posting here in the hope to prod it along for review or acceptance. The problem is that the dlopen/LoadLibrary code looks like it was hacked in instead of being added to the platform abstraction API and it doesn't support windows unicode builds out of the box. The patch fixes that problem and silences a warning generated by the new index format. bug... http://www.sqlite.org/cvstrac/tktview?tn=2023 patch... http://www.sqlite.org/cvstrac/attach_get/309/sqlite3.patch Regards, Brodie - To unsubscribe, send email to [EMAIL PROTECTED] - -- /\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \ - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] building sqlite on windows in Unicode
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. 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. 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. 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. -- D. Richard Hipp [EMAIL PROTECTED] - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] building sqlite on windows in Unicode
Check the requirements in: http://www.sqlite.org/copyright.html for patches and other submissions to SQLite. This could be what is holding up inclusion of the patch. Christian Brodie Thiesfield uttered: Hi, Building sqlite on windows in Unicode mode broke with the addition of the loadable extensions. I found a bug matching this problem and attached a patch to it to fix it a while ago, however I haven't seen any other comments or movement in the bug. I'm not sure what else needs to be done to have a patch accepted, so I'm posting here in the hope to prod it along for review or acceptance. The problem is that the dlopen/LoadLibrary code looks like it was hacked in instead of being added to the platform abstraction API and it doesn't support windows unicode builds out of the box. The patch fixes that problem and silences a warning generated by the new index format. bug... http://www.sqlite.org/cvstrac/tktview?tn=2023 patch... http://www.sqlite.org/cvstrac/attach_get/309/sqlite3.patch Regards, Brodie - To unsubscribe, send email to [EMAIL PROTECTED] - -- /\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \ - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] building sqlite on windows in Unicode
Hi, Building sqlite on windows in Unicode mode broke with the addition of the loadable extensions. I found a bug matching this problem and attached a patch to it to fix it a while ago, however I haven't seen any other comments or movement in the bug. I'm not sure what else needs to be done to have a patch accepted, so I'm posting here in the hope to prod it along for review or acceptance. The problem is that the dlopen/LoadLibrary code looks like it was hacked in instead of being added to the platform abstraction API and it doesn't support windows unicode builds out of the box. The patch fixes that problem and silences a warning generated by the new index format. bug... http://www.sqlite.org/cvstrac/tktview?tn=2023 patch... http://www.sqlite.org/cvstrac/attach_get/309/sqlite3.patch Regards, Brodie - To unsubscribe, send email to [EMAIL PROTECTED] -
