Hi all, I saw no more comments on this suggestion. It is very simple to program around this issue in user code, but I would like to see it fixed in the library level. Unless someone has made this work-around in his code, an application cannot work at the same time in Win9x and Win2k if there is any ansii char in the filepath. Costas
> -----Original Message----- > From: Costas Stergiou [mailto:[EMAIL PROTECTED] > Sent: Saturday, August 05, 2006 11:47 PM > To: sqlite-users@sqlite.org > Subject: RE: [sqlite] Problems opening db in win9x and utf8 filename > > > > > > I no longer have a win98 system to test with, but based on my > > understanding... > > > > os_win.c attempts to convert the filename from UTF-8 to UTF-16. If it > > succeeds, it calls CreateFileW; > Actually, there is a flag there that caused the convertion to UTF-16 to > 'fail' (it doesn't really fail, just that the utf8ToUnicode returns 0). > > > if it fails, it calls CreateFileA with > > the original string. > Exactly > > > CreateFileW is a nonfunctional stub on win98, so > > when you pass a UTF-8 filename sqlite takes that codepath and fails. > > An ANSI filename won't pass the UTF-8 conversion, so CreateFileA is > > called with the ANSI string. > Actually, in Win98 it will pass the conversion, but as I said above, the > function fails by a check: "if (!isNT())" > > > That doesn't necessarily explain win2k though. Perhaps the current > > user locale does not match the ANSI encoding of the filename you're > > passing in? Internally win2k only uses the Unicode version, so > > CreateFileA must do an implict conversion to Unicode using the current > > user codepage. > Now that I checked the code, it actually does. > Unfortunately, the way the code is setup makes it necessary for the caller > to check in which OS it runs and either use UTF8 paths or ansii ones. I > think this is not a good technique (and not actually intended from what I > have read in the docs) since the sqlite3_open does not give a truly > uniform > interface to the caller. > > My suggestion is this: > The sqlite3_open should always expect a utf8 path (as the docs say). If in > win2k everything works fine. If in win98 it should convert the path to > utf16 > and THEN convert it to ansii using the CP_ACP (current ansii code page). > This will work for 99.9% cases since in non-English win9x OS, almost 99.9% > ansii strings are in the system's locale. > I think this is also the expected behavior (and what I have programmed my > app to do, until I tested it in win98). > > To make these changes, all the logic of os_win.c should change to > accommodate the above. I would certainly say that the way it currently > works > is wrong (bug). > Of course, there is the problem of breaking existing code (since many > win9x > user will not have read the docs, or else someone would have mentioned > this > behavior looong time agoe). > To maintain compatibility (e.g. to accept ansii non-utf8 paths), a check > can > be made on whether the supplied path is in utf8 (heuristically this has > almost 100% success) and then do the above. > > Costas > > > > > MSLU does provide a functional CreateFileW wrapper for win9x, but I > > don't believe the stock sqlite binaries are built with it. > > > > > > On 8/5/06, Peter Cunderlik <[EMAIL PROTECTED]> wrote: > > > > > I think you will never succeed using UTF-8 encoded filenames on those > > > systems. I don't know how it can be done programmatically, but each > > > file or directory name has its 8.3 name as well, i.e. "Program Files" > > > would be "progra~1". I think this is the safest way how to pass > > > filenames to SQLite. It should work on Win 9x as well as 2K and XP. > > > > NTFS can have 8.3 shortname creation disabled. Systems running > > without it are not common but do exist, so you should avoid relying on > > them if at all possible.
