Hacker News new | ask | show | jobs
by badsectoracula 1403 days ago
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.

1 comments

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.