>culminating in the horror of the ribbon bar)

I'm sure this is still an unpopular opinion, but I've come around to the idea of the ribbon bar. Toolbars as they were pre-Office-2007 usually only contained duplicates of entries that were already in the menu. The menus are difficult to discover things in and limited to only showing text (at least in the "classic" sense like Office 03 used). Ribbon bars take the discoverability of a toolbar and make it use only as much space as a menu would. It's a solid compromise IMO.

> I'm still not sure that the move from actual buttons on a button bar to just a flat series of icons was right, and many such changes happened after that (culminating in the horror of the ribbon bar).

To be fair, they've left the classic mode in. Right click the taskbar, then click 'taskbar settings', scroll to the bottom and there's a dropdown for 'combine taskbar buttons'. Change it to 'Never' for the classic mode. (This is also present in Windows 7/8)

I prefer the new mode, less mouse movement required and looks tidier personally but it's nice the option is still there.

I meant the regular toolbars underneath the menus (in MFC it was CToolbar, I think), that in Win95 were a set of regular icon buttons, including a beveled edge.

Within a few Office and OS versions, that changed to first dropping the beveled edge, as we might realize that icons under the menu are buttons, and there would be less visual noise, then large buttons with icons + text, and finally getting into an incestous relationship with the menu and becoming ribbons.

(Although, I do the old-fashioned taskbar settings, too.)

> Not that my hopes are very high in that regard, as Linux and the BSDs didn't manage to do that either, despite having most of the technology and even doing some half-hearted attempts (CORBA was a part of early GNOME)…

D-BUS has taken up that role, but it doesn't get as much as COM/UWP, which many still don't realize that since XP the large majority of new Windows APIs are only available via COM, with a possible additional .NET wrapper on top.

DBUS would probably be closer to DCOM or even the Amiga's ARexx ports. Granted, with that plus XEmbed, you could get a lot of the benefits without an explicit object model/component system, but I haven't seen that done a lot in action. Linux users mostly go for 70s shell/pipes to cobble together parts. Better than nothing, but man, such wasted opportunities (and even something that doesn't require Lisp/Smalltalk/Oberon systems where everything is the PL anyway).

There's more GUI scripting done on Macs and Windows. Whole cottage industry automating Excel, for example…

I feel you, back when I look to some setups I hardly see any difference to my former self organising xterms in groups of four on a X Windows IBM terminal connected to a DG/UX server, in 1994.

Linux/BSD have the tooling, yet it is ChromeOS and Android that reap the benefits of such component based APIs.

KDE 2 was super scriptable through dcop, and also had embeddable UI compnents with KParts (or was that in 3?).

My first job after high school was QA for Lindows, and I used dcop to automate testing of their app store client (2002-2003).

It is still like that, however it doesn't help when people just stay on konsole and don't learn what their desktop is capable of.

> Win95 was pretty solid

Win98SE was the peak IMHO.

Nowadays I like KDE/Qt on Linux.

Note that I was only talking about the uniformity of the UI here. Stability-wise, every DOS Windows was pretty bad.

Win98SE's toolbar were those big mozilla-ish ones, right, with both text and icon and no button border? Other than that, I can't remember anything distinguishing about the 98 UI. Were gradient in the window bars introduced with 98 or SE?

Win98 shipped the IE4 "Desktop Update" webified-Explorer that was an optional install for Win95 IE4, then Win98SE was Win98 with IE5.

I agree, NT4 to me was the peak of MS greatness. How I miss the blue boot screen and the speed of use.