Re: Re: [sqlite] SQLite for Win32 TCHAR
=== On 2004-03-19, Will Leshner wrote === >On Mar 19, 2004, at 7:18 AM, Nuno Lucas wrote: > >> What I believe is in separation of the os.c file for the diferent >> platforms supported. >> A os_unix.c, os_win.c, os_mac.c (and maybe os.c for common code) >> separation will make the code for each port more readable and easy to >> set new ports (for example, ifdefing the incompatible code in os_win.c >> and adding a os_wince.c). > >Yes, I think this is a great idea. > hehe, let's lobby for it ;-) ~Nuno Lucas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite for Win32 TCHAR
=== On 2004-03-20, sword wrote === .. >So, what you want to do basically falls in maintaining ports, but >internally in SQLite codebase, isn't it? If I understood you correctly, yes. I just replyed to correct a litle misconception about the Windows CE port. I agree with you on patching sqlite to work under the Unicode environment (a very quick fix). About adding a Unicode API to sqlite, I don't, for now (until sqlite works with it natively). The reason is that as sqlite would convert to UTF8 anyway, it would not add nothing except maybe confusing the developer of why his database access was slower than his coleage (using the Ansi version). If you want this Wide API, is easy enough to make it yourself (as you probably have done, already). What could be missing in here is a contrib page where this kind of stuff could be exposed for all (it could be a wiki page, also). In this case, a .h/.c pair of files would do the trick, maybe titled wsqlite.h/.c. Another pair tsqlite.h/.c would expose the Win32 generic types interface. Regards, ~Nuno Lucas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite for Win32 TCHAR
On Fri, 19 Mar 2004 15:18:50 + "Nuno Lucas" <[EMAIL PROTECTED]> wrote: > I don't think there is the need to go so far. What I believe is in separation > of the os.c file for the diferent platforms supported. > A os_unix.c, os_win.c, os_mac.c (and maybe os.c for common code) separation will >make the code for each port more readable and easy to set new ports > (for example, ifdefing the incompatible code in os_win.c and adding a os_wince.c). > When compiling for windows, the os_mac.c and os_unix.c would simply be >ifdefed out, like when using SQLITE_OMIT_AUTHORIZATION and the auth.c file. > I didn't do this to the WinCE port because I think a port should be the closest >possible to the original, including the design, making it very simple >to use a program like WinMerge to update the sources to a new version. >For WinCE I had to also to implement atof() (for some WinCE versions), and >having it on a separate os_wince.c file would make the code cleaner. So, what you want to do basically falls in maintaining ports, but internally in SQLite codebase, isn't it? Actually, I don't care specific breed of Windows, but only have concern on the aspect (you can associate it with aspect-oriented programming) that they have same characteristics in necessary interfaces (ANSI/wide). Therefore I thought it would be advantage for SQLite to extract and abstract this aspect, ANSI/wide, to adapt it to unknown future platforms. If you only care about problems of short-range, just port and let it go, but I believe it won't produce maintainable and reusable code. My own usage model of SQLite is, I incorporate SQLite as source code in my C++ codebase of an application with UNICODE defined. Since UNICODE is defined all over SQLite code, to match Windows API and SQLite const char* zFilename interface and make it pass through the compiler, I have to modify os.c to add 'A' postfix to all file-handling APIs. Because I only use source code of SQLite, I can agree with your somewhat light-weight solution. However, SQLite is provided in binary .dll form, too. For users of .dll, only one dll for all Windows and unchanged interfaces would be some kind of merit, at least I'd thought so looking sqlite.org for years. I would like to hear the opinion of the designer himself on this point. If you assume ANSI/wide version APIs coexistence in SQLite is too fat and takes in a few unwanted kilobytes of code memory which is too big in embeded platform, then there should be a macro like LEAN_FILE_API or something to remove unwanted part from resulted binary, but it is only for Windows Embedded developers, not for mainstream desktop/server Windows developers. -- KL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite for Win32 TCHAR
On Mar 19, 2004, at 7:18 AM, Nuno Lucas wrote: What I believe is in separation of the os.c file for the diferent platforms supported. A os_unix.c, os_win.c, os_mac.c (and maybe os.c for common code) separation will make the code for each port more readable and easy to set new ports (for example, ifdefing the incompatible code in os_win.c and adding a os_wince.c). Yes, I think this is a great idea. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite for Win32 TCHAR
plz see below...
=== On 2004-03-19, sword wrote ===
>On Thu, 18 Mar 2004 16:01:39 -0500
>"Clark, Chris" <[EMAIL PROTECTED]> wrote:
>> > -Original Message-
>> > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
>> > Sent: Tuesday, March 16, 2004 11:58 PM
>> > To: [EMAIL PROTECTED]
>> > Subject: Re: [sqlite] SQLite for Win32 TCHAR
>> >
>> >
>> > So finally Ticket 239 http://www.sqlite.org/cvstrac/tktview?tn=239,2
>> > will be fixed soon, after 1 year the ticket was submit? (by adding 'A'
>> > to all file handling API in OS_WIN)
>>
>> If you do that you break the WinCE port. WinCE only has the wide versions (but we
>>have char and wide char). That's why the previuos posts have mentioned
>>mbstowcs()/wcstombs().
>>
>> Chris
No, the WinCE port will not be broken. It is a separate project and not using the same
code for windows, so a merge with the windows sources of sqlite (what I do for each
new version) will not break WinCE. Probably one or two fixes will be implied, but
nothing serious.
>OK, WinCE doesn't have CreateFileA symbol in its binary from the
>beginning.
>
>There will be 2 different scenarios for SQLite to adapt itself
>to Windows overall.
>
>1) Separate OS_WIN to OS_WINNT, OS_WIN9X, OS_WINCE, and
>maintain different SQLite binaries for them as ports.
I don't think there is the need to go so far. What I believe is in separation of the
os.c file for the diferent platforms supported.
A os_unix.c, os_win.c, os_mac.c (and maybe os.c for common code) separation will make
the code for each port more readable and easy to set new ports (for example, ifdefing
the incompatible code in os_win.c and adding a os_wince.c).
When compiling for windows, the os_mac.c and os_unix.c would simply be ifdefed out,
like when using SQLITE_OMIT_AUTHORIZATION and the auth.c file.
I didn't do this to the WinCE port because I think a port should be the closest
possible to the original, including the design, making it very simple to use a program
like WinMerge to update the sources to a new version.
For WinCE I had to also to implement atof() (for some WinCE versions), and having it
on a separate os_wince.c file would make the code cleaner.
>2) Put ASCII/wide version of those APIs side-by-side in os.c
>of SQLite, like sqliteOsOpenReadWriteA and
>sqliteOsOpenReadWriteW, and add user interfaces as sqlite_openA
>and sqlite_openW, then put CreateFileA and CreateFileW (CreateFileW,
>not CreateFile, is present as a symbol in WinCE binary as listed in
>http://www.xs4all.nl/~itsme/projects/xda/wince-systemcalls.html,
>right? ) in each versions, just like WindowsNT itself does. This way
>is what I suggested in the last paragraph of Ticket 239 comment of
>1 year before.
>
>http://www.sqlite.org/cvstrac/tktview?tn=239,2
I don't see the need for this. It will just complicate the code with litle value (not
the ticket, offcourse).
I will not detail myself here, as I think you were not well informed about the WinCE
port (I think I informed you now).
I wanted to see the ticket better, but it seems the tracker is down at the moment
(Richard ?).
If this helps, here is the error (http://www.sqlite.org/cvstrac/timeline):
-
Query failed
Database query failed:
REPLACE INTO access_load(ipaddr,load,lastaccess)
VALUES('213.205.69.139',1,1079709118)
Reason: attempt to write a readonly database
--
Well, regards,
~Nuno Lucas
>
>"Another way is, add to SQLite its own ANSI/Unicode(UCS-2) version
>APIs as Windows does, in Windows SQLite build. For example "open" is
>translated in sqlite.h to openA/openW which exists in dll. Fortunately
>SQLite has os.c as abstraction filter for its body, several changes in
>os.c will be sufficient."
>
>For sqlite.h,
>
>#ifdef UNICODE
>#define sqlite_open sqlite_openW
>#else
>#define sqlite_open sqlite_openA
>#endif
>
>this translation is sufficient, as you won't remove UNICODE symbol
>in Windows Embedded development.
>
>Win95 has CreateFileA (if you have installed Microsoft Unicode Layer
>to Win9X it also has CreateFileW), WinNT has both CreateFileA and
>CreateFileW, and WinCE has only CreateFileW. In current SQLite dll
>binary at http://www.hwaci.com/sw/sqlite/sqlitedll.zip contains only
>CreateFileA symbol as you can see it with Dependency Walker.
>
>Performance-wise for WinNT, when it takes CreateFileA it internally
>translates ASCII arguments to wide and passes it to CreateFileW, so
>it's recommended that you use Unicode filenames consistently in
>WinNT platforms.
>
>By the way, please
Re: [sqlite] SQLite for Win32 TCHAR
On Thu, 18 Mar 2004 16:01:39 -0500 "Clark, Chris" <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, March 16, 2004 11:58 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [sqlite] SQLite for Win32 TCHAR > > > > > > So finally Ticket 239 http://www.sqlite.org/cvstrac/tktview?tn=239,2 > > will be fixed soon, after 1 year the ticket was submit? (by adding 'A' > > to all file handling API in OS_WIN) > > If you do that you break the WinCE port. WinCE only has the wide versions (but we >have char and wide char). That's why the previuos posts have mentioned >mbstowcs()/wcstombs(). > > Chris OK, WinCE doesn't have CreateFileA symbol in its binary from the beginning. There will be 2 different scenarios for SQLite to adapt itself to Windows overall. 1) Separate OS_WIN to OS_WINNT, OS_WIN9X, OS_WINCE, and maintain different SQLite binaries for them as ports. 2) Put ASCII/wide version of those APIs side-by-side in os.c of SQLite, like sqliteOsOpenReadWriteA and sqliteOsOpenReadWriteW, and add user interfaces as sqlite_openA and sqlite_openW, then put CreateFileA and CreateFileW (CreateFileW, not CreateFile, is present as a symbol in WinCE binary as listed in http://www.xs4all.nl/~itsme/projects/xda/wince-systemcalls.html, right? ) in each versions, just like WindowsNT itself does. This way is what I suggested in the last paragraph of Ticket 239 comment of 1 year before. http://www.sqlite.org/cvstrac/tktview?tn=239,2 "Another way is, add to SQLite its own ANSI/Unicode(UCS-2) version APIs as Windows does, in Windows SQLite build. For example "open" is translated in sqlite.h to openA/openW which exists in dll. Fortunately SQLite has os.c as abstraction filter for its body, several changes in os.c will be sufficient." For sqlite.h, #ifdef UNICODE #define sqlite_open sqlite_openW #else #define sqlite_open sqlite_openA #endif this translation is sufficient, as you won't remove UNICODE symbol in Windows Embedded development. Win95 has CreateFileA (if you have installed Microsoft Unicode Layer to Win9X it also has CreateFileW), WinNT has both CreateFileA and CreateFileW, and WinCE has only CreateFileW. In current SQLite dll binary at http://www.hwaci.com/sw/sqlite/sqlitedll.zip contains only CreateFileA symbol as you can see it with Dependency Walker. Performance-wise for WinNT, when it takes CreateFileA it internally translates ASCII arguments to wide and passes it to CreateFileW, so it's recommended that you use Unicode filenames consistently in WinNT platforms. By the way, please don't confuse the argument above with TCHAR support all over SQLite, because SQLite won't support UTF-16 until SQLite 3.0 as its storable data. And I don't like simple ASCII/wide implicit translation wrapper to be incorporated in SQLite since it becomes unwanted overhead. Here I only talk about TCHAR filename and abstraction of file-handling interfaces. -- KL - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite for Win32 TCHAR
Hi, In 03/17/2004 07:35 AM, Nuno Lucas wrote: For the original poster: If you want a hint on how to do your wraping, > see the help on mbstowcs/wcstombs functions of the C runtime, > or MultiByteToWideChar/WideCharToMultiByte in the Win32 API. That's right. Nuno gives you a great hint. I'm using his sqlite WinCE port (that maintained on SF.net) and I wrote a small wprapper classes which do a ASCII <-> UNICODE conversion using MultiByteToWideChar/WideCharToMultiByte API calls. My wrapper uses string from STLPort by Giuseppe Govi (look at http://www.pocketpcdn.com/ ) internally and every string going out my wrapper is converted into TCHAR, LPTSTR or - what is even better - to WTL::CString class objects (which also provides some conversions if needed). Kind regards -- Mateusz Łoskot, mateusz at loskot dot net GNU/Linux (Slackware 9.1) http://counter.li.org #220771 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [sqlite] SQLite for Win32 TCHAR
This is to clarify what I meant: I would like to know if anyone has modified sqlite so that it entirely works with TCHAR, either when it is typedef'd as unsigned short or char (per UNICODE). This is an example of what I would like to see: sqlite *sqlite_open(LPTCSTR filename, int mode, LPTSTR* errmsg); typedef int (*sqlite_callback)(void*,int,LPTSTR*, LPTSTR*); int sqlite_exec(sqlite*, LPCTSTR sql, sqlite_callback, void *, LPTSTR *errmsg); and following this the underlying code fully supports TCHAR all down to the functions in os.c. In studying the code I realize its not a simple task and it may not even be possible or desirable considering the logic which supports UTF8 throughout. Other sources of concern are buffer sizes and how the changes would affect read/write performance etc Thanks for your feedback to this point, Mike Smith -Original Message- From: Steven Van Ingelgem [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 17, 2004 1:27 AM To: Andrew Francis; Michael Smith Cc: [EMAIL PROTECTED] Subject: Re: [sqlite] SQLite for Win32 TCHAR I understand what he means... I am using SQLite 2.8.11 and I did notice this too... Some Win32 fucntions should have 'A' attached to the end. This way it does not complain when using SQLite embedded in a UNICODE project. [ I even think I submitted a diff with things you would have to change to have absolutely no warnings any more (for a Win32 unicode build that is)] greets... At 06:11 17/03/2004, Andrew Francis wrote: Michael Smith wrote: Has anyone ported the SQLite code to support the Win32 TCHAR type and API? I'll confess I'm not actually sure what you mean by "ported" - do you mean using TCHAR (which is, btw, just a typedef for char or short depending on whether UNICODE is #define'd) in the sqlite library interface, or using TCHAR for Win32 calls? Regardless, I'd start by looking at the sqlite ports to Windows CE / PocketPC. From memory, there are a couple around. Windows CE provides only Unicode versions of the Win32 functions, so generally WinCE code has to be TCHAR/Unicode 'clean.' -- Andrew Francis Software Developer Family Health Software - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] G00fy, (aka KaReL, aka Steven) Main Webpage : http://komma.cjb.net <http://komma.cjb.net/> CQ Database : http://lid.fragland.net/ <http://lid.fragland.net/> ICQ #: 35217584
Re: [sqlite] SQLite for Win32 TCHAR
So finally Ticket 239 http://www.sqlite.org/cvstrac/tktview?tn=239,2 will be fixed soon, after 1 year the ticket was submit? (by adding 'A' to all file handling API in OS_WIN) Aside from it, since Win9X is really diminishing, SQLite should start to adapt itself to 'NT way' if it purports Windows support... -- KL On Wed, 17 Mar 2004 6:48:55 + "Nuno Lucas" <[EMAIL PROTECTED]> wrote: > Oops... > I realize now that the fix for compiling for windows when UNICODE is defined is in > my TODO list. > I was waiting for it to be fixed in the main code, to minimize the changes from the > original code. > In the total, there are only a dozen changes to the code in "os.c". I can also make > a patch, if that is desired. > > Regards, > ~Nuno Lucas > > === On 2004-03-17, Nuno Lucas wrote === > >Just a litle correction > > > >=== On 2004-03-17, Andrew Francis wrote === > >... > >> > >>Regardless, I'd start by looking at the sqlite ports to Windows CE / > >>PocketPC. From memory, there are a couple around. Windows CE provides > >>only Unicode versions of the Win32 functions, so generally WinCE code > >>has to be TCHAR/Unicode 'clean.' > >> > > > >All WinCE ports I know of (including the one I try to maintain - > >sqlite-wince.sf.net) just wrap the OS specific functions to work with the Unicode > >only available Win32 API functions (and a few tweaks to make synchronization work). > >The sqlite API is unchanged, just the UTF8 is enabled by default. > >I don't see any advantage in creating a Unicode specific sqlite API, as this can be > >done by a simple wraper made by the user (that all C++ programmers out there would > >make, anyway by creating their object encapsulation to sqlite C API). > >The only thing I can say about my WinCE port is that it compiles on normal windows, > >too, reverting to the original sqlite source code (compiling with or without > >UNICODE defined). > > > >For the original poster: > >If you want a hint on how to do your wraping, see the help on mbstowcs/wcstombs > >functions of the C runtime, or MultiByteToWideChar/WideCharToMultiByte in the Win32 > >API. > > > >Best regards, > >~Nuno Lucas > > > > -- > /"\ > \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL > X - AGAINST MS ATTACHMENTS > / \ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite for Win32 TCHAR
Oops... I realize now that the fix for compiling for windows when UNICODE is defined is in my TODO list. I was waiting for it to be fixed in the main code, to minimize the changes from the original code. In the total, there are only a dozen changes to the code in "os.c". I can also make a patch, if that is desired. Regards, ~Nuno Lucas === On 2004-03-17, Nuno Lucas wrote === >Just a litle correction > >=== On 2004-03-17, Andrew Francis wrote === >... >> >>Regardless, I'd start by looking at the sqlite ports to Windows CE / >>PocketPC. From memory, there are a couple around. Windows CE provides >>only Unicode versions of the Win32 functions, so generally WinCE code >>has to be TCHAR/Unicode 'clean.' >> > >All WinCE ports I know of (including the one I try to maintain - sqlite-wince.sf.net) >just wrap the OS specific functions to work with the Unicode only available Win32 API >functions (and a few tweaks to make synchronization work). >The sqlite API is unchanged, just the UTF8 is enabled by default. >I don't see any advantage in creating a Unicode specific sqlite API, as this can be >done by a simple wraper made by the user (that all C++ programmers out there would >make, anyway by creating their object encapsulation to sqlite C API). >The only thing I can say about my WinCE port is that it compiles on normal windows, >too, reverting to the original sqlite source code (compiling with or without UNICODE >defined). > >For the original poster: >If you want a hint on how to do your wraping, see the help on mbstowcs/wcstombs >functions of the C runtime, or MultiByteToWideChar/WideCharToMultiByte in the Win32 >API. > >Best regards, >~Nuno Lucas > -- /"\ \ /ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Re: [sqlite] SQLite for Win32 TCHAR
Just a litle correction === On 2004-03-17, Andrew Francis wrote === .. > >Regardless, I'd start by looking at the sqlite ports to Windows CE / >PocketPC. From memory, there are a couple around. Windows CE provides >only Unicode versions of the Win32 functions, so generally WinCE code >has to be TCHAR/Unicode 'clean.' > All WinCE ports I know of (including the one I try to maintain - sqlite-wince.sf.net) just wrap the OS specific functions to work with the Unicode only available Win32 API functions (and a few tweaks to make synchronization work). The sqlite API is unchanged, just the UTF8 is enabled by default. I don't see any advantage in creating a Unicode specific sqlite API, as this can be done by a simple wraper made by the user (that all C++ programmers out there would make, anyway by creating their object encapsulation to sqlite C API). The only thing I can say about my WinCE port is that it compiles on normal windows, too, reverting to the original sqlite source code (compiling with or without UNICODE defined). For the original poster: If you want a hint on how to do your wraping, see the help on mbstowcs/wcstombs functions of the C runtime, or MultiByteToWideChar/WideCharToMultiByte in the Win32 API. Best regards, ~Nuno Lucas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [sqlite] SQLite for Win32 TCHAR
I understand what he means... I am using SQLite 2.8.11 and I did notice this too... Some Win32 fucntions should have 'A' attached to the end. This way it does not complain when using SQLite embedded in a UNICODE project. [ I even think I submitted a diff with things you would have to change to have absolutely no warnings any more (for a Win32 unicode build that is)] greets... At 06:11 17/03/2004, Andrew Francis wrote: Michael Smith wrote: Has anyone ported the SQLite code to support the Win32 TCHAR type and API? I'll confess I'm not actually sure what you mean by "ported" - do you mean using TCHAR (which is, btw, just a typedef for char or short depending on whether UNICODE is #define'd) in the sqlite library interface, or using TCHAR for Win32 calls? Regardless, I'd start by looking at the sqlite ports to Windows CE / PocketPC. From memory, there are a couple around. Windows CE provides only Unicode versions of the Win32 functions, so generally WinCE code has to be TCHAR/Unicode 'clean.' -- Andrew Francis Software Developer Family Health Software - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] G00fy, (aka KaReL, aka Steven) Main Webpage : http://komma.cjb.net CQ Database : http://lid.fragland.net/ ICQ #: 35217584
Re: [sqlite] SQLite for Win32 TCHAR
Michael Smith wrote: Has anyone ported the SQLite code to support the Win32 TCHAR type and API? I'll confess I'm not actually sure what you mean by "ported" - do you mean using TCHAR (which is, btw, just a typedef for char or short depending on whether UNICODE is #define'd) in the sqlite library interface, or using TCHAR for Win32 calls? Regardless, I'd start by looking at the sqlite ports to Windows CE / PocketPC. From memory, there are a couple around. Windows CE provides only Unicode versions of the Win32 functions, so generally WinCE code has to be TCHAR/Unicode 'clean.' -- Andrew Francis Software Developer Family Health Software - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
