Re: File name encoding and GTK ABI compatibility on Win32

[Mike Hearn <mike navi cx>]

Owen Taylor wrote:
> I don't think anybody (including Microsoft) would exhibit windows.h
> as an example of convenient, easy to use programming.

There are many, many things wrong with the Win32 API, but the ease of 
binary distribution you get with it isn't one of them.

> What it prohibits is making things "just work better" ... the 
> g_return_if_fail() change saved on the order of 5% code size for GTK+.
> That's a pretty huge win.

It doesn't prohibit it, things can just work better for apps that 
explicitly target the new GTK+ version.

> Having to put -DGTK_ABI=2.6
> would still confuse the heck out of beginning programmers, and cause
> a big mess in the header files. 

I don't see why it would be any more confusing than "Hey Bob, check out 
my leet new GTK+ program ... huh, it doesn't work for you?". Specifying 
the version of an API you want to target is a tested technique that 
works well.

As far as making a mess of the header files, I don't think it's such a 
big deal. It typically involves wrapping new functionality in an #ifdef. 
For Tors need, you could do:

#if (GTK_TARGET_MINOR >= 6)
#  define U(x) x ## _utf8
#else
#  define U(x) x
#endif

void U(gtk_some_function)(GtkFoo *foo, gboolean bar);

This is slightly ugly, but not hugely so - it's still easily readable - 
and the portability gains are useful.

> If people want their programs to have a prayer of working with older
> versions of GTK+, they need to be testing extensively with those older
> versions. (It's not just functions and enumerations that get added.
> There's also semantic creep where combinations of function calls that
> didn't used to work start working.) And at that point, we might as
> well say "compile with the oldest version you want to run with.

I'm not really convinced by this - are there many examples of 
applications actually depending on this semantic creep? I can't think of 
any off the top of my head, certainly it should be the exception rather 
than the norm.

In the case that an app depends on stuff that was broken in previous 
versions, yes there is nothing you can systematically do about this. If 
apps depending on previously buggy stuff is so common that it affects 
library policy like this then maybe a longer beta cycle is needed to cut 
down the amount of buggy code being shipped.

thanks -mike