Re: Bug #101792...

["J. Ali Harlow" <ali juiblex co uk>]

On 2004.08.24 14:58 Tor Lillqvist wrote:
[snip re. Windows and UTF-8 encoded filenames]

> But, now I have partly changed my mind. At least, we shouldn't break
> binary compatibility. We can't change the ABI of existing entry points
> in the GLib DLL. If somebody upgrades GLib on his machine to 2.6,
> GLib-using applications will break horribly if g_dir_read_name()
> starts returning UTF-8 names (and the application then proceeds to try
> to open such file names). I don't want to see the mess this would
> cause. GLib has been very good at keeping DLL versions binary
> compatible so far.

Clearly if we go down the route of getting g_dir_read_name() to return
UTF-8 encoded filenames then we will be breaking ABI, but we can handle
this by making 2.6 incompatible with 2.4 if we want to.

> I think we must keep unchanged ABI for the existing entry points in
> the GLib DLL.
>
> What we could well do is require minor source-level changes as apps
> are compiled and/or linked with GLib 2.6. When handling file names
> that originate from GTK or GLib, applications should change their
> open/fopen/stat/rename/etc calls to g_open/g_fopen/g_stat/g_rename/etc
> instead, if they want to continue to work with non-ASCII file names on
> Windows.
>
> I suggest we use some preprocessor hacks to achieve this. For example,
> the entry point g_dir_read_name in the GLib DLL would continue to
> return file names in the system codepage. But, the headers for GLib
> 2.6 would cause an application calling g_dir_read_name() to actually
> call something called g_dir_read_name_utf8() on Windows.

That's also possible, and would have the great advantage of keeping ABI
but I'd be worried that people would start using both variants if we
weren't careful to discourage them. I'd like to think we could get rid
of the system codepage variants in the next ABI breakage.

> One could even arrange to have open/fopen/stat/etc entries in the GLib
> import library (entries that wouldn't be DLL stubs but real object
> files), that would print out some link-time warning (is this possible
> with ld? I am pretty sure it is possible with Microsoft's linker) (and
> at run-time call the corresponding g_ wrapper function). Hmm.

This, on the other hand, is a really bad idea. The last thing I want is
Gtk+ getting in the way of me calling win32 functions.

Cheers,

--
J. Ali Harlow
ali juiblex co uk