[bt-devel] Unicode impl on Windows (was Some pictures)

Matthew Talbert ransom1982 at gmail.com
Thu Feb 26 10:08:26 MST 2009


2009/2/26 Troy A. Griffitts <scribe at crosswire.org>
>
> Dear Matthew,
>
> I'm sorry, but I don't remember you telling me that BibleCS did not work for you.  I just tested under Windows XP and it works fine for me.
>
> I'm sorry to disagree technically with you again (nothing personal) but getenv and open should be consistently implemented on whatever platform for which a C compiler is attempting to build working executables.  These methods were created long before Unicode, but now on Unicode-aware systems compilers need to make a choice what to do as 'The Right Thing' and open should AT THE VERY LEAST, be consistent with getenv.  If I receive a PATH NAME from getenv as a char *, then I should be able to pass that returned value to open.  I don't care if the impl uses 'short 8.3' DOS name alternatives, or UTF-8 (of course the best solution), they should be consistent.  The OpenFileW system call is a brute force method to do the right thing on windows, which is fine to get something working, but the implementation of the C call 'open' should call the correct system call (OpenFileW, CreateFileW, whatever) on whatever operating system for which it is implemented.
>
> In summary, the whole point of a compiler even supplying an implementation of the stdlib C calls is to allow a developer to avoid calling OS level calls like the Win32 API direct calls you cite.
>
> Do you understand my point?
>
>   -Troy.

Of course, I understand how you would *like* things to work.
Unfortunately, that is not how they do work. I clearly wrote in my
email what I tried and that it didn't work with BibleCS. I suggest you
try the same filename on a FAT32 partition and see if it works. Also
note that this situation is dependant on the locale, so what works for
you in English, may have a very high probability of failing in
Chinese, and vice-versa. The internet is full of articles on this.

Again, your desires to have a consistent C implementation do not
unfortunately correspond with reality.

Matthew



More information about the bt-devel mailing list