=== 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
=== 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
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
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 ad
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
-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
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
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
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
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
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
11 matches
Mail list logo
