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 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] ---------------------------------------------------------------------- /"\ \ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL X - AGAINST MS ATTACHMENTS / \ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
