Exactly right on bling. I was trying to figure out a good name for interface "features" that really didn't do anything useful, but were flashy. Bling was it, and it's not complimentary.
In Windows Vista, the new search features are a bit flashy and probably do use a lot of clock cycles while indexing in the background, but they're actually useful, and should be stolen and imitated by others.
Bling is stuff like the translucent Aero windows that gain the user nothing in utility, and eat up a lot of clock cycles (which is where we started with this conversation). I don't like "dashboards" and the like for similar reasons...though others do.
I'm that way too -- I was agast at the bloated code that young programmers write professionally a few years ago. When I asked why not write more efficient code the response was "so what? its user interface and doesn't need to be optimized". Well, they paid dearly for that attitude about a year later when the whole program was so slow that the customer wouldn't accept it.
About Windows 1.0 and MS-DOS 1.0 -- I remember those too. DOS version 1.0 did not have any support for subdirectories and Windows 1.0 was all text based, no graphics or fonts other than the operating systems default font. It ran on top of DOS instead of integrated with it.
I think that it's important to realize that 99% of the code does not need to be efficient. The argument that it's just UI code is really valid. That having been said, it's a lot more important to realize that the 1% of code that needs to be efficient needs to really efficient. I think that it was the 1% that was the undoing of the folks you were talking about. They probably never learned to recognize when efficiency is important and how important it is at such times and also had not learned how to make code efficient when it needs to be.
As an old-timer myself, I learned to program at a time when efficiency was almost always important. So I learned to write really tight code. But as the years rolled by and processors got faster and the speed of human beings remained more or less constant, I began to realize that speed and simplicity of coding was usually more important than the number of cycles consumed.
I have concluded that every programmer needs to learn how to write maximally tight code, but also when to write maximally tight code.
Perhaps you're right, because I don't know enough about Linux to know whether it had a background indexing service (yes I know about grep, awk and and other command line searching and parsing utilities, as I'm also a Unix programmer, but I'm not a sysadmin).
Windows had the Indexing Service in (at least) Win NT, Win 2000, and Win XP (maybe Win95 and 98), that ran in the background to build an index that could use a search string to find and retrieve documents on the hard drive quickly. Unfortunately, that background service always slowed Windows down, often to a crawl, so most people disabled Indexing.
The current version of that indexing service in Vista is much quicker, and doesn't interfere with foreground tasks as much.
I don't know enough about Mac OSX to know whether it has an indexing service or not.
The kernel was - originally - made in C++. Lower-level systems, such as system drivers, use C. Also, many core files (like the user interface!) were also made using C++, due to it being object-oriented. Our own Billy just worked on BASIC, and reviewed some code, but after BASIC his part was done.