.. well, FAT certainly wasn't. But yes, VFAT probably is. Not that I want
to look at it ;)
Well, if it uses a 8-bit codepage, then that means that as far as the
POSIX filename interface is concerned, it has nothing what-so-ever to do
with Unicode (ie unicode is just a totally invisible internal encoding
issue, not externally visible).
I assume you have to use some insane Windows-only UCS-2 filename function
to actually see any Unicode behaviour.
Sad. Because there really is no reason to use a local 8-bit codepage when
you could just use UTF-8.
So the CreateFileW() is the "native UTF-16 interface", and CreateFileA()
is the 8-bit codepage one that has nothing to do with Unicode and is
purely some local thing.
But for a UNIX interface layer, the most logical thing would probably be
to map "open()" and friends not to CreateFileA(), but to
CreateFileW(utf8_to_utf16(filename)).
Once you do that, then it sounds like Windows would basically be Unicode,
and hopefully without any crazy normalization (but presumably all the
crazy case-insensitivity cannot be fixed ;^).
So it probably really only depends on whether you choose to use the insane
8-bit code page translation or whether you just use a sane and trivial
UTF8<->UTF16 conversion.
Anybody know which one cygwin/mingw does?
Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html