Win32 programs from 2000 work on the latest Win32 and get new functionality that is exposed through the APIs they used at the time, where that applies.

Gtk programs from 2000 do not work on the latest Gtk, regardless of if the functionality they used from the APIs they relied on would be found in the latest Gtk. Instead they have to be "ported" to the new Gtk, assuming the source code is available, the developers are available and someone is willing to waste effort and time to do the porting.

This is a nonsensical comparison though. New versions of GTK are actually new APIs. So what you are saying is more like "WPF programs do not work if you delete WPF and try to compile it against only the Win32 API" which is also correct. GTK1 programs will continue to work on GTK1, it has not changed.

> This is a nonsensical comparison though. New versions of GTK are actually new APIs.

Which has been my entire criticism! Gtk major versions being "new APIs" is what breaks backwards compatibility and causes existing applications, libraries to waste time keeping up.

It actually worse than Win32 vs WPF because the latter is something you can ignore as Win32 is still receiving improvements with bug fixes and new functionality, but Gtk development for any previous major version eventually stops all development. Not only that but even with new APIs, under Windows there is always some official way to use the previous APIs together with the new (e.g. mix Win32 with WPF) but there isn't anything like that for GtkN-1-with-GtkN (and even if there was it'd be pointless in long term as GtkN-1 would eventually stop working, unlike Win32).

>but Gtk development for any previous major version eventually stops all development.

Then your actual criticism is that those previous versions have stopped development, not that backwards compatibility was broken. The whole thing about "backwards compatibility" is a distraction. And again, it is not a waste of time keeping up if they actually want the new features. If they do not want them then they are free to spend their time maintaining the old versions.

No, my actual criticism is that backwards compatibility was broken, not that previous versions stopped development - such a concern about stopping development only exists because the newer versions were not backwards compatible.

That does not follow. WPF is also not backwards compatible and you have no issue with that, because Win32 is still being maintained so that makes you feel you can ignore WPF. Am I wrong here?

I have issues with WPF too since i think Microsoft should have focused on improving Win32 instead of wasting their resources (and, most importantly, the time of everyone who felt at the time they had to keep up - see the Joel article i linked elsewhere), but bringing up WPF doesn't serve anything aside from muddling the discussion.

The only areas where i see WPF doing better is that at least it allows merging Win32 and WPF code, so an application can improve partially if they see WPF as a valid path forward - and it doesn't present itself as Win32 v2 so that Win32 development can continue independently (remember that i wrote that WPF is something you can at least ignore). None of these are the case with Gtk though.

But again, mentioning WPF here serves no purpose, what i wrote so far should be clear enough by itself.

I only mention WPF because you brought up Win32. If you can acknowledge it is not completely the same then maybe do not bring that up at all. The drawing part of the Win32 API is actually probably closer to Xlib and Xaw than it is to GTK. And those libraries have not really changed in 30 years or so. With some hacking I bet you could get Xaw widgets to display in a GTK4 window.

That Joel article is more of a rant than a coherent statement, it is not reasonable to ask developers to stop working on new APIs and libraries.

>None of these are the case with Gtk though.

But this is incorrect, development can continue independently on old versions of GTK.

> I only mention WPF because you brought up Win32.

I brought up Win32 because it retains backwards compatibility for decades and still gets bug fixes and new features, WPF is as relevant to the discussion as Qt would be.

> The drawing part of the Win32 API is actually probably closer to Xlib and Xaw than it is to GTK.

The Win32 API provides way more functionality than Xlib (Xaw is a separate toolkit and unrelated to Gtk) and is closer to a toolkit like Gtk.

> That Joel article is more of a rant than a coherent statement, it is not reasonable to ask developers to stop working on new APIs and libraries.

What Joel asked (well, he didn't ask, jut put forward) was about wasting developers' time chasing new APIs that do the same things like the old APIs because they are afraid they're going to remain behind and the old APIs will stop getting any form of support or development.

Like what Gtk does to older major versions, basically.

> But this is incorrect, development can continue independently on old versions of GTK.

The entire idea of having an "old version of Gtk" that some 3rd party developer(s) continue on to keep backwards compatibility could only be a possibility because the actual Gtk developers do not care about keeping backwards compatibility.