While i sit here watching gvfs shit itself randomly because of a minor glib version bump. This kind of crap is why there is still no "year of the desktop".
WinAPI and glib are different things. Compare WinAPI to libc API and Xlib. And I'm sure, you can run X application from 1990 on current Linux. I've learned X programming in 2005, and many resources and mans were dated 1990-1995. They all worked.
Though OpenSource often tends to move forward without thinking much about compatibility, that's right. I guess, it's not an interesting topic for hackers, who work in their free time.
It's an interesting exercise to pull up an old (but reasonably complex) Xlib app and run it on a modern machine; xfig, for example.
They never pause for breath. Like, you cannot see the application think. Ever. Whenever you ask it to do something, it responds instantly. You click the mouse, and by the next frame the app has updated and is waiting for your instructions.
It's astonishing how much nicer this makes them to use.
(And it's interesting that the Xaw classic design is... um... well, it's as ugly as hell, but it's a kind of functional ugliness which you stop seeing after a bit. Motif, on the other hand, remains awful. The really interesting one of the old widget sets is Open Look, which still looks elegant and polished today: http://www.daylight.com/dayhtml/doc/thor/thor.sample3.gif)
I wonder if there's any mileage in resurrecting one of these old widget systems? Update it to work with modern languages and desktop environments, make sure the accessibility's up to scratch (Motif got this right; don't know about Xaw and Open Look), make sure that modern workflow menus-and-windows apps can be written using them...
I bet you could compile an old Xlib (or Xt/Motif) application on Linux, but good luck running a binary from way back when -- the libc/glibc and a.out/ELF switch should put breaks on that.
On the other hand, if your actual premise is open source, there's simply less incentive of avoiding breaking binary compatibility. I bet there were a few angry words and stomped feet in the last decades at Microsoft because of having to maintain that.
Not that glib/gtk are poster childs for even source-level compatibility, not even within one major version. There's a reason why several projects are switching to Qt.
(I'm doing my Cato bit here: I still think that they should've done an Xt toolkit instead of inventing the wheel yet again. There certainly was some experience there, given that GIMP 0.x was written for Motif.)
You'd certainly need to go through a _lot_ of hoops to make it run - a number of X extensions have come and gone, and even assuming you're not consuming some additional library and are just writing X calls...
...Linux 0.01 didn't come out until 1991, so you'd be hard-pressed to find a compatible binary from 1990. ;)
Yeah sorry. But when i see MS having such a commitment to backwards compatilbity, and then the supposed "vanguard" of desktop Linux can't even be bothered to keep things working within their domain (while trying to dictate how everyone needs to build their distros to be "user friendly" and attractive to developers no less) i just get riled up.
It's super impressive! But it won't run on 64 bit Windows.
I recently wrote a simple 32 bit Windows app that runs on 3.11 (with the 32 bit subsystem installed) through Windows 10. On the more recent Windows versions it supports theming and it's per-monitor high DPI aware. That is to say, it looks and works like a modern app.
To do this I had to build it as a freestanding binary with MingGW and do some version probing and dynamic DLL lookups but altogether it wasn't too hard.
Did you consider Github or similar for this? Sounds superb and plays exactly into the strength of MS Windows - compatibility and high performance when using Win32 API.
I abandoned the project as soon as my curiosity was satisfied. If I ever revisit it I’ll upload it to somewhere and submit here because indeed it’s worth sharing.
