57/26/17

Week of July 23, 2000

Back in the early days of MS Windows there were no toolbars. The only thing avant garde about Windows was its File Manager, a single utility which took as much code as UNIX Version 7. It is File Manager which is credited with creating the market turn around for Microsoft Windows.

Philippe Kahn's Borland was way ahead of the game. They dubbed Microsoft's development environment, the Programmers Work Bench or PWB for short, 'Programmers Waste Basket' and they were not far off. Borland had 'speed bars' back then.

Speed bars worked on a raster technology using a small checked (dithered) bitmap embedded in every executable. When a button was enabled it appeared as in its glyph bitmap; when it was to be disabled the checked bitmap was masked over it, giving it a kind of 'washed out' look. This was sufficient.

The Borland idea needed color to look good. Microsoft hated color. Used to being the brunt of hate and dissatisfaction everywhere, Microsoft had learned to keep a low profile even on the desktop. It was hard to hate Windows - it was so unobtrusive. Microsoft taught that there were only two colors which never incurred negative response: blue and gray (what else is new - welcome to the corporate world). They tried to stay completely within this spectrum.

Early Microsoft utilities had 'toolboxes' and the standards for these toolboxes were strict and well written. All toolbox bitmaps were to be 28x28 pixels in size, and there were six pre-defined states: enabled, pushed, released, checked, radio checked, and indeterminate. These states corresponded exactly to those of the Windows button class with its push buttons, radio buttons and check boxes.

Glyphs were to be gray scale only. No other color was to be used. The only allowed (or at least accepted) gray scale colors were black [RGB(0, 0, 0)], (dark) gray [RGB(128, 128, 128)], silver or light gray [RGB(192, 192, 192)], and white [RGB(255, 255, 255)]. Of course any dither effect with these colors could be used.

The sole exception to this rule was the use of burgundy or maroon [RGB(128, 0, 0)] for outlining glyphs for the checked button states.

There was no raster technology back then in Redmond. All glyphs for all toolbar buttons for all six states had to be included in the executable, and the technology hard coded into each as well. On a dead (blank) client area clicks were monitored, last coords for the click kept, and buttons adjusted as need be. Even Visual Basic programmers found need for this 'technology'.

When Borland hit the streets with their product lines for Windows 3.0 and Windows 3.1 they left Microsoft miles behind. Their products were better, more stable, faster, and more inspired. And everybody loved the Borland 'speed bars'.

Microsoft's response came with the release of Windows 3.11 and the first edition of the common controls library. This library is today almost as (in)famous as Windows itself is, but back then it was hardly noticed. The common controls library was so named because it served all of two applications in Windows 3.11: File Manager and Print Manager. Both had status windows run by the library, and both sported what Microsoft aptly christened 'toolbars'.

Early Microsoft focus group studies would show that these toolbars were immensely popular. The conclusions of the early batches were that only 26% of Windows users would gravitate towards the application menu, a mere 17% would bother with application accelerators, but a walloping 57% would click on the toolbars. The toolbars were here to stay.

The common controls library had an open interface. This was not something Microsoft was worried about initially, until they noticed ISVs hacking into it, whereupon they assigned Kyle Marsh, then with MSDN support, and Wes Cherry of Excel and Solitaire fame, to come up with an ISV version.

The result, MSTBBTN, was available as dynamic and static link, with full source included. Messrs. Cherry and Marsh pulled a neat hat trick indeed. Sticking to the original Microsoft toolbox standard as much as possible, they'd come up with a neat masking trick to reduce the number of button state glyphs needed in executables. Their 'hack' could not emulate the RGB(128, 0, 0) checked standard, and - of historical significance - it worked fine only if you stuck to the Microsoft gray scale standard. As soon as you attempted to introduce color, things got very messy indeed.

The Microsoft 'chiseled stone' standard for the disabled state was very effective, but its masking technique depended on glyph colors being gray scale. Anything dipping under RGB(192, 192, 192) would most likely turn up as a dark gray blotch - very unflattering. But as long as you stuck to the gray scale, you were ok.

Radsoft apps back then had Radsoft's own toolbar engine, similar to the Borland speed bar, but rather than embed a bitmap in every executable - an anathemic thought if there ever was one - a sequence of two fast raster ops was used to accomplish the same trick.

The Microsoft look was standard though and its acceptance was growing, despite rather obnoxious attempts by Central Point and Norton to introduce extremely elaborate systems with buttons almost bigger than the application windows themselves. The hitch was color: the Radsoft engine, more than even Borland's, was dependent on color to get a 'washed out' look for the disabled state; Microsoft decried color, claiming it was 'childish' and made the application look cheap, a claim their common controls technology forced them into, as it wouldn't work with color at all. Yet most ISVs bought the Microsoft pitch in the long run, Radsoft among them.

Word 2.0 was the first Microsoft application to use color in its toolbar (it never used the common controls engine), and then only a discreet yellow (which would be interpreted as white by the engine) and dark blue (interpreted as dark gray). In other words, Word was Microsoft's weather balloon for using color - and hearing Microsoft reps now worming out of previous categorical claims that color was cheap could be very amusing.

The common controls library for Windows 95 was a major technological step forward. No longer were ISVs required to write in their own code for each and every module - the toolbar engine was resident in the system. Toolbar engines everywhere were scrapped when this transition took place (Radsoft's among them), as the logic of still supporting one's own now non-standard engine was redundant at best and futile at worst.

But a curious thing happened with the release of Windows 95: color happened. Suddenly toolbar glyphs were bright and aglow with every wavelength in the spectrum. Yet the underlying technology had not changed: it still made a mess out of chiseling colored glyphs. So Windows 95, with Explorer in the lead, decided to not bother about disabling glyphs anymore, but do like the Word team had done all along: issue a 'beep' instead. This was ironic, unfortunate, and even tragic, as the one superior feature of the Microsoft toolbar engine was no longer used.

You create two outlines of the glyph, destroying all middle range colors, the first in dark gray displaced +1/+1 onto the button, the second in white with no displacement: this simply does not work with the colorful Windows 95. Certain buttons did work, and Microsoft was at pains to find color combinations and glyph standards so the entire operation did not have to be scrapped. In particular, Cut, Copy, Delete, Paste, Save and Undo made it through as workable glyphs.

Generally speaking then, this toolbar technology has served ISVs well. There was no longer any need to create and embed a toolbar engine of one's own - apps got leaner. There was a standard - good for everyone. The interface could be honed and tweaked to leave only minimal start up code before the toolbar could be left running on its own. Altogether a satisfactory experience.

But nothing too good lasts long. With the advent of the browser war Microsoft was at it again, and this time their graphics designers were outdoing themselves. The Internet Explorer 5 toolbar engine is certainly one of the most advanced UI tools ever made for the Windows platform, its bells oozing out of its whistles. The glyphs have again grown, from 15x16 for Windows 3, 16x16 for Windows 4, to 22x20: a disproportionate standard similar to Word's from the old Win16 days.

And this new engine with its new glyphs resplendent in their 8-bit color is even less suitable to the chisel. Taking any of these images, incorporating them into a toolbar, and letting the toolbar disable them is pure disaster. Again, Microsoft opted to not let buttons visually reflect their state but startle users with an annoying 'beep' instead.

Not that you can't make decent 'disabled' glyphs of course: it's just that the toolbar engine cannot, and to construct these images manually is to take the technology wheel and spin it right back to the early 1990's when everything had to be blitted by hand.

The colors are nice, the application UIs are attractive, but the built-in engine cannot and will not adequately handle it. We're back to square one again.

The new X-bar technology from radsoft.net is incorporated into the 2001/MMI distribution of the XPT.