Re: Bug #101792...

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

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.


J. Ali Harlow
ali juiblex co uk

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]