[cairo] [PATCH] script: More compatible with C89 and VC++.

[Tor Lillqvist]

> It does appear, because Microsoft refuses to do it, that the only solution
> is to wrap all the UTF-16 API's in a POSIX emulation that does UTF-8,
> translating it as necessary to UTF-16.

Which, incidentally, is exactly what GLib (and GTK+) do;) (Except that
there really is no POSIX emulation involved as such.)

> I am not suprised that they purposely break the portable functions

I don't want to be seen as a Microsoft apologist, but I'll take the risk.

It's all because of preserving backward compatibility, isn't it?
Everything is always easy if one can ignore history and break API.
Programming is hard, let's go shopping.

On Win9x UTF-16 was not involved. There file names indeed were just
bytes, at all levels. Can you imagine the uproar it would have caused
if Microsoft's C then on NT-based systems would not have had APIs like
fopen()? (Instead, would have had only wchar_t ones like wfopen()?)

(As such, I doubt there even was any standard wchar_t type when the
first Microsoft C compilers came on the market. I am fairly sure there
was no UTF-8.)

(So yeah, it would be cool if there was an alternative modern C
library for Windows that would be totally UTF-8-oriented. One can hope
Microsoft at some stage sees the light...but I don't hold my breath.)

Anyway, it isn't as if when programming for Unix systems it would
necessarily be much easier to handle file names completely correctly,
safely and at the same time elegantly either. On Unix file names are
just arbitrary sequences of bytes. At sites with old file systems that
have a long history of being used from various Unixes in the past,
even if now perhaps then mainly from Linux, especially outside
English-speaking countries, one can not reasonably expect that file
names would all be just ASCII, or if not then encoded in UTF-8. One
has to be very careful to use file names exactly as they are on disk
with file APIs, but still not pass strings containing file names as
such to modern APIs like in GTK+ and cairo that expect UTF-8.

> In any case such fixes are probably not Cairo's responsibility,

Indeed.

--tml