If one GUI's not enough for your SPARC workstation, try four

Who needs a jack-o-lantern when you've got a bright orange gas plasma display?

This is a 1990 Solbourne Computer S3000 all-in-one workstation based around the 33MHz Panasonic MN10501, irreverently code-named the Kick-Ass Processor or KAP. It is slightly faster than, and the S3000 and the related S4000 and later S4000DX/S4100 directly competed with, the original gangsta 1989 Sun SPARCstation and SPARCstation 1+. Solbourne was an early SPARC innovator through majority owner Matsushita, who was a SPARC licensee in competition with Fujitsu, and actually were the first to introduce multiprocessing to the SPARC ecosystem years before Sun themselves did. To do this and maintain compatibility, Solbourne licensed SunOS 4.x from Sun and rebadged it as OS/MP with support for SMP as well as their custom MMU and fixes for various irregularities in KAP, which due to those bugs was effectively limited to uniprocessor implementations. Their larger SMP systems used Fujitsu (ironically), Weitek and Texas Instruments CPUs; I have a Series5 chassis and a whole bunch of KBus cards Al Kossow gave me that I've got to assemble into a working system one of these days.

This particular machine is a fairly upgraded unit thanks in large part to Stephen Dowdy, formerly of the Solbourne Shack and the University of Colorado, where he maintained them. In particular, besides tons of OS stuff and documentation, the SBus RAM expander card giving this machine a total of 56MB ECC RAM came from his old S3000, and it also has a SCSI2SD along with a 256K L2 cache CPU module stolen from an S4100. The 1152x900 monochrome display is compatible with the SBus bwtwo. Just like I retain a great fondness for PA-RISC because it was my first job out of college, I have similar affection for Solbournes because one of my first undergraduate Unix accounts was on a department Series6.

KAP was an interesting processor with a great name, but its sometimes serious issues more or less directly led to Solbourne's demise as a computer manufacturer because Matsushita wouldn't let them walk away from its sunk design costs. Still, it was good competition when it was new and OS/MP was nearly 100% compatible with SunOS 4.x (4.1C, the final release, is equivalent with SunOS 4.1.3), so what you're really looking at is a SPARCstation "clone" of sorts with the hottest display this side of a Al Gore climate chart.

And it turns out that particular computing environment was really the intersection point for a lot of early GUI efforts, which were built and run on Sun workstations and thus will also run on the Solbourne. With some thought, deft juggling of PATH and LD_LIBRARY_PATH and a little bit of shell scripting, it's possible to create a single system that can run a whole bunch of them. That's exactly what reykjavik, this S3000, will be doing.

This is a direct grab from the bwtwo framebuffer using Solbourne's included screendump utility (which also works from a remote session so you can capture things "in the middle") and emits rasterfile images. The details of my wired internal network are blacked out because you don't need to know them, you naughty little voyeur; just look at the motd for our menu of choices.

The only trick we'll need for this show-and-tell is that OS/MP screendump(1) emits a different header than Sun rasterfiles even though the image data, at least for this display hardware, is the same. To get ImageMagick and xv happy with opening them, this is sol2sun.c, which takes a Sol rasterfile on standard input, rewrites the header, and emits a Sun rasterfile on standard output. It compiles with either the included cc or gcc. Note that it currently requires a big-endian system because that's how I roll.

#include <stdio.h>

/* expects 1152 x 900 (129600 byte) bwtwo framebuffer image */
/* see rasterfile(5) for the Sun format; this strips the Sol header and
   puts on a Sun one */

#define XSIZE 1152
#define YSIZE 900
#define BITSPERPIXEL 1

#define SIZE    ((XSIZE*YSIZE)/(8/BITSPERPIXEL))

int main(argc, argv)
int argc;
char **argv;
{
        char *x;
        int *y;

        x = (char *)malloc(SIZE);
        if (!x) {
                perror("can't allocate memory");
                exit(255);
        }
        if (!fread(x, 1, 8, stdin)) { /* skip header */
                perror("can't fread()");
                exit(255);
        }
        y = (int *)x;

        if (y[0] != 0x797a3220 || y[1] != 0x2e242120) {
                fprintf(stderr, "expecting Sol raster file 1152x900 1bpp (got 0x%08x 0x%08x)\n", y[0], y[1]);
                free(x);
                exit(255);
        }

        /* big endian */
        y[0] = 0x59a66a95; /* oh oh oh it's magic */
        y[1] = XSIZE;
        y[2] = YSIZE;
        y[3] = BITSPERPIXEL;
        y[4] = SIZE;
        y[5] = 0x01;
        y[6] = 0x00;
        y[7] = 0x00;

        fwrite(y, 4, 8, stdout);
        fread(x, 1, SIZE, stdin);
        fwrite(x, 1, SIZE, stdout);
        free(x);
        exit(0);

/* notreached */
        return 0;
}

The images below thus were captured with screendump(1), converted to Sun rasterfiles on the S3000 with sol2sun, transferred to and previewed with xv on my Raptor Talos II to ensure sanity and quality, and finally turned into PNG with ImageMagick because I love each and every one of you and you wouldn't be able to view them easily otherwise (probably).

As shown we have four environments we'll be exploring: Bellcore ManaGeR (MGR), Sun's SunView and OpenWindows 3, and more or less for comparison vanilla X11R6 (with both olvwm and twm). Conveniently, this is also their order chronologically. Since the system's booted and we're already getting sunburned from that screen, let's get started.

MGR

MGR, short for ManaGeR, is our first graphical environment. It has an animated splash screen which is quite distinctive.

As the copyright indicates, MGR was originally developed at Bellcore. Bellcore was one of the spinoffs from the 1983 AT&T breakup as a way for the Baby Bells to have their own research consortium separate from Bell Labs, which the now involuntarily svelte AT&T retained; the remnant of Bellcore survives today as Ericsson's iconectiv subsidiary. SunOS was MGR's first and native platform, initially written by Stephen Uhler on an early Sun 68K workstation in 1984 (probably a Sun-1) and demonstrated at USENIX Fourth Computer Graphics Workshop in 1987.

The version we're exploring here is 0.69, the last release known. Despite the 1988 copyright date this release actually hails from 1996, although most of the changes since its 1989 source release (hi, Rich!) relate to bug fixes, portability enhancements, refactoring and some extra client applications. This final release was preserved by Michael Cardell Widerkrantz, who ported it himself to Solaris. It runs on Linux 0.99 or better (not sure how much luck you'll have with current kernels though), FreeBSD (ditto), Sun-3 and Sun-4 workstations with SunOS 4.1.2+, and Coherent. Various older versions of MGR ran on the classic Macintosh, OS-9 (as opposed to the classic Mac), LynxOS, VxWorks, Atari ST MiNT, Xenix, 386-Minix, DEC 3100, and the AT&T 3B1 UNIX PC (7300).

Michael's binary distributions, however, lack most of the clients. I took the source code he had available and rebuilt it from scratch, fixing a couple minor miscompiles and bugs along the way, and adding a simple ismgrterm.c since curiously the source lacks it. This is the code running here.

If you want to try this on your own compatible SPARC, though I caution I only vouch for its proper operation on a monochrome Sun framebuffer, I offer both a full binary distribution (mgr-0.69-full-sunos413.tar.gz) or source with pre-built artifacts (mgr-0.69-src+obj-sunos413.tar.gz), both of which are on the Floodgap gopher server. Most people will want the former. Decompress and un-tar it in /usr (as root); it will create /usr/bin/mgr (as ./bin/mgr) and /usr/mgr (as ./mgr), which contains the entirety of the clients, man pages, fonts, static libraries, compiler headers and icons. Finally, insert the entries in /usr/mgr/misc/termcap.sunos into /usr/share/lib/termcap, followed by tic /usr/mgr/misc/terminfo.sunos, so that the correct terminal entries are installed. We'll talk about why that matters momentarily.

/usr/bin/mgr is a convenience C-shell script I threw in that adds /usr/mgr/bin to your PATH and /usr/mgr/man to your MANPATH before running the main binary, since some binaries name-conflict with other existing tools. Despite what you may read, you don't need to run it as root. Everything is statically linked (except of course for libc and so forth), so no library shenanigans are necessary. That script is what got us here, so let's have a look around.

On initial startup there's nothing but a mouse pointer.

The left mouse button, however, pulls up a simple menu: new window, redraw or quit. If we select a new window, a rectangle appears allowing us to draw the dimensions of the new window. In turn, that yields ...

... a terminal window. In fact, at its core, MGR is really just a collection of graphical terminals that happen to resemble windows. No sockets are involved, nor IPC: communication is almost entirely through escape sequences and ASCII to and from the terminal, meaning you could run MGR applications over Telnet or rlogin, or even a serial connection using a modem.

For example, we'll use the shape utility to set a window size for us (shape 80 40). But /usr/mgr/bin/shape uses none of the provided libraries: it's just a shell script. To set the terminal window to 80x40, it checks that the terminal is MGR (the /usr/mgr/bin/ismgrterm utility I recreated) and then emits {ESC}80,40w. In fact, if you echo that sequence yourself on the command line, it does the same thing. Let's widen the dimensions out a little more and look at what we have in /usr/mgr/bin.

Not all of these probably work quite right and there are bugs or uncompiled portions that may have escaped my notice, but this seems to be at least the vast majority of clients the standard distribution came with. There were some other tools with MGR support distributed separately such as Emacs and PBMplus but we'll stick to what it came with out of the box.

To show off its graphical capabilities, let's start with hilbert, which fills up the screen with a Hilbert curve. This runs quite quickly because once the drawing command is processed it goes straight to the framebuffer. MGR's low overhead makes it very responsive.

Much like Tektronix terminals or other graphical terminals, the terminal emulation supports vector drawing (lines, ellipses and so forth), as well as text in various fonts. A simple library is provided for the convenience of C programmers but any program can emit the escape sequences (see doc/ in the source distribution for a list).

Some of the clients are ported versions of X clients. As a demonstration of ellipse drawing and the ability for a program to actually receive UI data, here's mgreyes.

And yes, it's the MGR equivalent of xeyes, following your mouse pointer around. Like hilbert, mgreyes uses the terminal size you set.

Of course, you can resize windows at will with the mouse too, not just programmatically. Another context menu pops up when you left-mouse over an open window instead of empty background space. This menu lets you move, resize (stretch), cut and paste, bury (lower) or entirely destroy the window.

We've resized it here, but what about bitmaps? We'll demonstrate that with another ported X client to display the phase of the moon, mphoon (here the mphoon_small variant).

It not only resizes the window to the bitmap size but also centers it. The original bitmap is an XBM; the program draws it and the moon phase shading to an internal buffer, flips the bit order (MGR doesn't use XBM bit order), and dumps it to a file which it passes to the MGR library to upload. Over a remote link where a local file is not available, the bits are actually passed over the terminal connection. We'll move it back ...

... and, since it doesn't respond to CTRL-C to stop it, use the context menu to simply destroy it.

MGR comes with a whole library of icon clip art in /usr/mgr/icon, which /usr/mgr/bin/browse can show us.

Clients can define their own context menus, which are accessed on the middle mouse button. We advance pages in browse with it, which receives the selected option over standard input. Notice there's the cursor still at the bottom: this is after all "just" a terminal window!

Second page of icons. There are a lot.

Fonts are provided too in /usr/mgr/font, though the font browser has a more typical button-driven interface. Here we'll use /usr/mgr/bin/mgrshowfont to browse the roman fonts it comes with.

Icons for previous, next and quit are drawn, and respond to mouse clicks as if they were buttons (with the right mouse button instead of the middle one so that menus also work); the client also receives them as standard input.

While all fonts are monospace, they come in a variety of sizes, slants and weights. Earlier versions also supported Hershey vector fonts.

I think that's enough for one night, so we'll quit. When we select the quit option, a second menu comes up to "really quit" along with alternative choices to suspend your session or lock your screen.

Incidentally, one of the other notable clients ported to MGR is this implementation of Boulder Dash, played with the keyboard. It's not bad at all.

MGR's approach is not without its quirks. Clients can't open windows on their own — they can only operate in windows you've already opened for them. (Death to popups! MGR web browsers for the win! But that also means multiple document interfaces are effectively impossible without a lot of kludges.) Also, this implementation does not allow you to move windows even partially offscreen. That would seem like a crippling limitation on a 512x384 compact Mac but perhaps its version could do so; sadly, I don't have it and don't know where to find it. A solution for a small screen system might just be to have a stack of fullscreen terminals you flip between. Plus, clients can get feedback from the MGR library that a bitmap is too large for the display (hence the different sizes of mphoon), so potentially they could adapt.

Because MGR is just an overgrown terminal type at its core, it should be possible to write a MGR "terminal emulator" on modern systems so that these programs and others could live again. Maybe that's a project we'll do for a future entry; in particular, if we have one instance per window, then your regular window manager can just manage the windows. It wouldn't be the full experience but it would certainly suffice. Unfortunately, MGR passed away largely into obscurity as X became more entrenched and comparatively performant, which is a shame because I like its speed, its lack of network overhead, and the fact that just about anything that can accept and receive data from the terminal can be an MGR client.

SunView

SunView, short for Sun Visual/Integrated Environment for Workstations, is nearly as old as MGR. It was introduced in 1985 as a standard part of SunOS 3.x with Sun's new Sun-3 68020-based workstations, and Solbourne provides it as part of OS/MP, so nothing needed to be installed to run it. Including a full graphical environment out of the box in the mid-1980s was years ahead of most other commercial Unix vendors. The version that comes with SunOS 4.1 and OS/MP is SunView 1.80, though SunView's separate version numbers were generally concealed from the casual user.

Oddly Sun scatters SunView clients in several places, mostly in /usr/bin/sunview1, but a few symlinked into /bin and /usr/bin, and a separate set of demos in /usr/demo/sunview1. We'll put all of these paths in our PATH before we start the environment with, simply enough, sunview.

There's no splash screen, but there's no blank screen either: SunView, at least by default, comes up with a console shell window, along with icons for a clock, another shell window (called cmdtool) and a text editor. These icons are in fact minimized running clients.

You can certainly start things directly from a shell window, but you also have a (partial) selection of SunView clients available with the right mouse button menu. Earlier versions of SunView used a simpler menu.

Parenthetically, Sun called the left, middle and right mouse buttons on their 3-button mouse the select, adjust and menu buttons respectively, and you'll see this in documentation from the era.

We selected the Command Tool; this opens another shell window (the same as the iconified shell client already running).

I talked at length about how MGR was just TTY communication: a "hello world" client on MGR could be as simple as echo hello world && cat > /dev/null. SunView isn't that. Instead, it provides libraries to draw primitives, widgets and windows and display them on the framebuffer, which means you have to write SunView clients in C or a ABI-compatible language. Here we've written and compiled a trivial "hello world" client, linking it against libsuntool (SunView was originally called SunTools), libsunwindow and libpixrect.

When run a new window opens with "hello world" on the title bar. The frame below it is a standard default control. In the documentation Sun calls these subdivisions of windows tiles. A text control with a scrollbar consists of two tiles, one for the text frame and one for the scrollbar. Tiles (within a window) can't overlap, but windows (that contain tiles) can.

Windows have their own right-mouse-button context menus for managing them. Close is actually the option to minimize to an icon. As a shortcut you can move a window with the middle button, though it has the well-intentioned annoying quirk that if you try to move it from the middle, it snaps motion to the vertical axis only. Here we'll just quit.

When we quit the window, by default an alert comes up to confirm, and even snaps the pointer to the confirm button so you can just double click. All of this is provided by the toolkit libraries; we didn't write any code for it. Other more useful examples are in the SunView System Programmer's Guide (modulo changes in the latest version [large PDF], which is naturally on Bitsavers).

Icons can be customized, as we see with the clock, or SunView can provide a default. Here, notice that the hands on the icon move with the time.

Restored, it gives you the time and date.

We close it to return it to an icon.

A unique shell option with SunView is the Graphics Tool, or gfxtool.

The graphics tool provides a separate canvas for drawing as well as a traditional shell window. This is for those programs that expect to write to the entire framebuffer: this gives them a virtual one.

You can see this function most clearly with the demonstration graphics applications; /usr/demo/sunview1/spheresdemo draws shaded spheres in the canvas portion of the window but the terminal section of the window remains untouched.

Oddly, fileview, SunView's default file manager, is not part of the context menu and must be started manually. Here we are looking at the root directory. Notice the diagram showing file interrelation.

Clients can have pull-down menus but they're implemented more as context menus for buttons, such as this example of fileview's File menu. Remember this convention because we'll see it again in the next environment.

The files themselves have their own separate context menu options.

Here's the properties sheet for the install kernel, showing a window push-pin control (the thumbtack) and checkboxes as well as a regular button. All of this is provided by the toolkit.

We won't go through everything that SunView can do, but here's what's installed by default. Notably mailtool is a GUI mailer (no mail to show on reykjavik, though), but the one that's most interesting to me and one I might try when I have a bit more space on the desk is adjacentscreens, which lets you span the desktop to another video card. This S3000 went bananas when I tried to install a secondary sga20 colour card but Stephen says a second bwtwo worked fine.

The text editor (textedit) is the other client that starts up by default besides the clock and shell terminals.

The text control subwindow has its own cascading context menus that the client can customize.

In fact, cmdtool uses the same basic control, with its own client-specific menu options.

SunView also includes icon and font editors (again, monospace bitmap). Here they are along with the system preferences tool, which it calls the "Defaults Editor."

And what workstation desktop would be complete without a selection of nerd performance monitoring tools? (I should note MGR had these too, we just didn't run any.)

The only gripe I have is that they're stupidly small by default and it took me a couple seconds to see where it even opened.

There are options for remote access as well, but these are just shells (such as with rlogin). Unlike MGR which can send everything over the terminal link, or X which is network-oriented, SunView is strictly local: there are no provisions for running a remote app with a local display. But that also makes it quick.

Quitting SunView brings up another snap-mouse-to-default-button dialogue box so that you can accidentally close all of your applications quickly if you're shivering.

OpenWindows

You might think it was weird that the company that coined "The Network Is The Computer" — in 1984! — did not itself deliver a networkable graphical environment. Well, so did folks at Sun. In 1986 the successor to SunView was developed, the Network extensible Window System, or NeWS.

SunView is limited and exclusively runs on the local machine, but it was small, it was fast and it worked. NeWS, on the other hand, became yet another example of second-system effect. Its most enduring technical advance was a cooperatively-multitasking PostScript interpreter for displaying multiple windows, an implementation different from but that would directly inspire Display PostScript in NeXTSTEP and more or less in the modern macOS. NeWS' PostScript implementation expanded the language with object-oriented constructs and inheritance that could provide everything from soup to nuts, from the underlying programming to the actual rendering and data. As such, the interpreter was very capable but correspondingly quite large by the standards of the day and performance was unimpressive. Unfortunately, because the C API was low-level and difficult, NeWS developers tended to write the entirety of their applications in PostScript which magnified these problems.

The nail in the coffin was Sun's licensing. In November 1986 InfoWorld reported NeWS releases for System V/386 Release 3 (SVR3 386) and BSD 4.2, but VP and software products general manager Eric Schmidt (yes, the Google guy) said in the same article it would have to be paid for ("this is what we did with the Network File System," he said in defense) and source code wouldn't be available until spring of 1987, meaning companies couldn't even start on porting it to their own graphics hardware until they shelled out. This plan made NeWS increasingly unpopular with software and operating system developers alike. X version 10, meanwhile, was free, and the growing body of supported applications forced Sun to add it to NeWS by customer demand, but the implementation was slow and buggy and when X11 became available Sun ended up developing a new hybrid window server (xnews) that could run both X11 and NeWS clients. That spelled the end of NeWS as a standalone product, and despite its announcements for other operating systems it was never itself the primary graphical environment for any released version of SunOS.

Meanwhile, Sun and AT&T were collabourating on a project to consolidate BSD, Unix System V and Xenix into the next release of Unix, SVR4. Part of this work in 1987 and 1988 was a new GUI specification with input and licensed patents from Xerox and their PARC division. Although SVR4 would not replace the BSD-derived SunOS 4 until 1992 (as Solaris 2), the new GUI was separately released as an abstract specification in 1988 called OPEN LOOK. OPEN LOOK derived substantial aspects of its appearance from conventions established in SunView, and defining it as a look-and-feel rather than tying it to any one implementation made the potential of multiple licensed implementations possible. (Competitors of course cried foul and consolidated into the Open Software Foundation as a counter, which developed Motif.)

Naturally the first implementation of OPEN LOOK to market was Sun's, which was merged with xnews to create the initial release of OpenWindows. First released in 1989 as a separately-licensed addon for SunOS 4, OpenWindows runs NeWS, X11 and SunView clients all in one window server. It uses OPEN LOOK as its GUI specification, and because significant portions of OPEN LOOK map closely or directly to SunView, the XView toolkit made it fairly easy to transition older SunView applications to run natively on X. NeWS code could itself become OPEN LOOK compliant with The NeWS Toolkit (TNT), and for those programs where the source code was lost or unavailable, NeWS clients and legacy SunView clients would still run too. As for new applications, Sun encouraged developers to write them around the OPEN LOOK Interface Toolkit (OLIT) which ran on top of Xt Intrinsics. Replacing the SunView window manager was olwm, the OPEN LOOK Window Manager, which was entirely spec-compliant.

The release here is OpenWindows 3.0, the last version compatible with SunOS 4. Although OpenWindows became a standard part of SunOS with 4.1.1, Solbourne never licensed it and only ever offered SunView with OS/MP. Fortunately, because of OS/MP's exceptionally high SunOS compatibility, OpenWindows 3.0 off a regular SunOS install CD runs pretty much without comment. So here we are.

OpenWindows has a splash screen. Yay!

OpenWindows is where I spend most of my time on the Sol, so I actually have it a little bit customized with a closed (minimized) console, a command tool (cmdtool, just like SunView — now you know the rest of the story) and a clock.

The application menu in olwm is now pinnable but is still accessed the same way as SunView with the right (menu) button.

In fact, most of the UI conventions from SunView remain in olwm, except that window motion is now with the left (select) instead of middle (adjust) button, the vertical axis snap quirk is thankfully eliminated, and there are a few other minor changes with how menus open and close. We'll start with that most important of desktop applications, solitaire.

Xsol is just an X application and runs as such. It doesn't use OPEN LOOK.

But the File Manager is fully OPEN LOOK compliant and arguably the most canonical example.

In particular, notice how much of the interface descended directly from fileview in SunView, including the button menu drop downs and the filesystem tree.

Interestingly, there are separate property sheets both for individual files and the entire File Manager itself.

And you can dismiss them simultaneously, too. A great way to clean up lots of scattered windows.

By default double-clicking the application menu (the triangle) will iconify a client, not quit it.

xnews in this release more or less implements X11R4, so things like NCSA Mosaic will work, amusingly using Motif as its toolkit ...

... and so will Netscape Communicator, here in version 4.61 which is the last release supported on SunOS 4.

A few little remnants of NeWS survive in the application menu such as the NeWS Clock.

For comparison here are three more clock applications running "together" along with the clock we started with. On the top left is the NeWS clock, in the middle is the SunView clock we saw before, and on the right is vanilla xclock.

SunView support in OpenWindows has some graphical problems that were never fixed since most applications depending on it had a reasonably straightforward upgrade path through XView. Two of those glitches we see here, an unusual clear space around the window and also redraw problems with the title bar (caused by motion of the mouse pointer). There was also a slight performance penalty to support SunView apps, so Sun had a -nosunview option to disable it. Interestingly this has an unexpected consequence: display spanning is also disabled when SunView is disabled, because OpenWindows 3.0 uses SunView adjacentscreens to implement it. This wasn't fixed until SunView support was completely removed in OpenWindows 3.3 and Solaris 2.3 (but XView applications were X-based, so they were unaffected).

Another place that NeWS remnants visibly persist is in the toolkit demonstrations. There is one for OLIT (Xt) and one for TNT (NeWS).

The OLIT demo is straightforward (bottom) but the TNT demo spawns a huge stack of windows each demonstrating different features of the toolkit. Interestingly, the SunView clock uses the same SunView window menu.

For OPEN LOOK the window context menu appearance is more updated but is clearly a descendant.

An interesting directional submenu.

That's one way to do a modal dialogue box!

The user-friendliness also manifested in a large amount of online help. This is another place where NeWS' legacy is felt because the OpenWindows Help Viewer is a descendant of NeWS' help viewer — and that makes sense given it's basically just displaying documents. As you would expect, the documentation is written in PostScript.

As such, help documents can contain vector graphics and multiple proportional font faces, and can be hyperlinked together. This has superficial similarities to the online help in the Common Desktop Environment (CDE), but only via convergent evolution; CDE help files are actually SGML.

In fact, a rather extensive number of "handbooks" came with the system, all browseable.

Some even had multimedia content. This document has buttons that cause audio to be played (the Sol has the same audio hardware as the SPARCstation), again all written in PostScript. Could this have become Sun's answer to HyperCard?

Unfortunately the snap-to-default-button system modals carried over from SunView too, but at least the default button is now Cancel, as the door hits us on the way out.

Like SunView, which finally disappeared completely with Solaris 2.3, OpenWindows' fate was to be slowly subsumed by descendants of its own technologies. The same release (3.3) that ended support for SunView also replaced NeWS with true Display PostScript (licensed from Adobe), and X support with true X11R5 code, completely obsoleting xnews. This new less-singing less-dancing window server was called Xsun. However, OPEN LOOK still persisted because it was built on top of Xt anyway, so it was unaffected, and XView applications still ran. (In 1990 Unix System Laboratories, formed as a spinoff from AT&T, went their own direction with OPEN LOOK and developed MoOLIT which preserved the same API but allowed any toolkit, even Motif, to underlie it. It was used by AT&T and Lucent almost exclusively; few vendors had an interest. USL was acquired by Novell in 1993.)

In 1993 major Unix vendors (Sun, USL, Novell and AT&T through the Univel joint initiative, SCO, HP and IBM, famously termed the "SUUSHI" partnership) concurred that the fragmentation fallout from the Unix Wars was counterproductive against their common enemy Microsoft. To actually make a practical effort at standardization the vendors notably agreed to make standards out of their already existing technologies instead of new ones (one of the few counterexamples to this obligatory xkcd). This was the Common Open Software Environment initiative, and as part of COSE, Sun agreed to mothball OPEN LOOK and adopt the Motif-based Common Desktop Environment originating from HP-UX's VUE. CDE came out in 1995 and became the default desktop environment with Solaris 2.6 in 1997, which a certain author of this blog remembers migrating to on an O.G. Sun Ultra-1, and XView and OLIT compatibility were finally removed along with olwm with Solaris 9 in 2002.

As a post-script, although open source versions of OPEN LOOK have since emerged and OWacomp restores compatibility to Solaris 9 and 10, Sun and AT&T were the only licensed implementors ever of their own specification.

X11R6

After all that drama our last stop is anticlimactic: good old X version 11. The history of the X Window System from its origins with MIT's Project Athena in 1984 is well-known and I won't discuss it much here. Solaris 2 (the first release of Solaris) was not universally loved upon its release and independent of the major change in philosophy from BSD to SVR4 there were many complaints about its performance on older hardware. The 68K Suns were completely cut off, and while early SPARCs were supported by Solaris for at least the first few versions, many shops elected to stick with old school SunOS which Sun attempted to retcon as Solaris 1. Solbourne never licensed Solaris, and while reportedly some early versions had hacks for SMP Sols, this IDT Sol was never one of those machines. It runs OS/MP and thus SunOS 4.1.3 to this day.

Because OpenWindows wasn't being updated for SunOS 4 either (OpenWindows 3.0.1 was specific to Solaris 2.0), if you wanted to run later applications that required X11R5 or X11R6 you would need to run X11R5 or X11R6. Happily, the available source code would build and run just fine on original SunOS. Binaries are available from the Floodgap gopher server.

I guess this is a splash screen. To avoid conflicting with OpenWindows, our X11R6 launcher script installs a separate LD_LIBRARY_PATH and PATH to supersede the other existing libraries.

This particular binary release comes with olvwm (note spelling!), an enhanced version of the OPEN LOOK Window Manager based on OpenWindows 3.2. It uses the original OPEN LOOK libraries for look and feel, which of course we have. The most notable enhancement is a true virtual desktop which can be much larger than your actual display. The virtual desktop schematic is the window at top right.

The desktop menu is much simpler, but cmdtool is still there, or you can run a real xterm.

No SunView support for you, though!

The File Manager does work, however.

And the window menu is also largely maintained, as you would expect coming from the same (later) code.

No NeWS support for you either!

Fine, I'm leaving. The dialogue modal still snaps to Cancel.

Just to prove it's "real" X11R6, you can still just run twm:

But where's the fun in that?

It's interesting that of all the window managers we've looked at in this article, only twm lets you move the window before it opens.

So let's just browse the net with xgopher and call it a day, huh?

From a computing archaeology perspective it's actually rather useful to have all these environments together in one place to compare and contrast. While they can't all run at once it's nice that they can still share one system. I think MGR has the greatest potential for a comeback because of its unique architecture, but it's OpenWindows I find I like the most: compatibility is good, performance is brisk, it runs most things fine, it has a lot of built-in apps, and the OPEN LOOK design is pleasant, unique and friendly. With it losing out to CDE I'm not sure the superior product won. Other contemporary operating systems had their own bespoke environments but I don't think the Sun-4 architecture can be matched for being the epicentre of so many at one time.

Just don't ask me to run Wayland on it.