File name encoding and GTK ABI compatibility on Win32

[Tor Lillqvist <tml iki fi>]

In 2.6 the GLib file name encoding convention will change drastically
on Win32. All GLib functions that take or return file names will start
using UTF-8.

For the rationale for this, see bug #101792 . Until now GLib has used
the so-called system codepage, which in Western locales is a
single-byte character set such as CP1252, and in East Asia is a
double-byte character set. The filename-related API in the Microsoft C
library uses the system codepage, and also has parallel functions that
use UTF-16.

Naturally, this would mean that existing GLib-using applications or
libraries, that have been compiled with some previous versions of GLib
2.x, and expect said functions to take or return file names in the
system codepage, would break horribly.

To avoid this, for all GLib functions that manipulate file names that
have existed prior to 2.6, preprocessor #defines have been added to
the corresponding headers that suffix the function names with _utf8
(on Win32 only). For instance a call to g_dir_read_name() actually
gets compiled as a call to g_dir_read_name_utf8(), etc. The
corresponding GLib source files then also define backward
compatibility versions of the functions with the old name, that behave
like before.

For GLib this has been relatively straightforward.

So, what about GTK? I started with gdk-pixbuf. There was only four
functions affected there, and it was quick to add the ABI
compatibility wrappers. I already have committed that.

But in gtk the number of affected functions is much larger. Just
GtkFileChooser would need 11 backward compatibility wrappers if I
counted correctly. Is this really something we want to do? At least I
am getting a bit scared... Not that the needed functions are
complicated, for example:

gchar *
gtk_file_chooser_get_filename (GtkFileChooser *chooser)
{
  gchar *utf8_filename = gtk_file_chooser_get_filename_utf8 (chooser);
  gchar *retval = g_locale_from_utf8 (utf8_filename, -1, NULL, NULL, NULL);
  g_free (utf8_filename);
  return retval;
}

Or should we bite the bullet and declare binary compatibility broken
on Windows for GTK 2.6 (and thus use a different name for the GTK 2.6
DLLs)?  (In that case, I should revert the ABI backward compatibility
functions from gdk-pixbuf.)

Please note that when recompiling applications with GLib 2.6 and GTK
2.6, one will need to make changes to the code that handles filenames
returned from GLib and GTK in any case: On Win32, said filenames will
now be in UTF-8, and cannot be used as such to construct pathnames to
be passed to C library functions like fopen() or stat(). That's why
the "gstdio" wrappers like g_fopen() and g_stat() are there. Is this
by itself enough reason to rename the DLLs? ("DLL renaming" means more
or less the same as "changing the soname of a shared library" for
ELF.)

--tml