RE: [sqlite] Win32 coders: change os.c?

nary compatibility and old sqlite_open intact, #ifdef UNICODE #define sqlite_open sqlite_openW #endif may be better. -- KL On Fri, 21 Nov 2003 16:23:31 -0600 "Rob Fowler" <[EMAIL PROTECTED]> wrote: > Thanks for the insight, Arthur. I guess since you're us

RE: [sqlite] Win32 coders: change os.c?

Thanks for the insight, Arthur. I guess since you're using Sqlite as a DLL, you *could* switch on UNICODE within your own app, although I understand why you don't. I'm using the Sqlite source files within my app directly. I switch on UNICODE so that the rest of my app (outside of Sqlite) can use

RE: [sqlite] Win32 coders: change os.c?

he SQLITE_UTF8 macro is defined? I have assumed that it is only those string parameters which are SQL statements. Tim > -----Original Message- > From: Rob Fowler [mailto:[EMAIL PROTECTED] > Sent: Friday, November 21, 2003 3:14 PM > To: [EMAIL PROTECTED] > Subject: RE: [s

RE: [sqlite] Win32 coders: change os.c?

Thanks, Chris. I mistakenly thought that all Windows platforms supported the 'A' versions of those functions. That's the kind of feedback I was looking for. Perhaps my suggestion still makes sense for desktop versions. I don't know. As I mentioned in my reply to Arthur, when the 'A' functions *

RE: [sqlite] Win32 coders: change os.c?

e one ending with an 'A'. As it stands, the os.c has no ability to deal with wide characters, so there is no reason it should ever call the wide version of these Win32 functions. Thoughts? Regards, Rob Fowler -

[sqlite] Win32 coders: change os.c?

above, os.c should always call the 'real' function name, and it should be the one ending with an 'A'. As it stands, the os.c has no ability to deal with wide characters, so there is no reason it should ever call the wide version of these Win32 functions. Thoughts? Regards, Rob Fowler