SAIC Galaxy 1100: a pre-CDE VUE of the PA-RISC with a security clearance

Even though I'm a Power ISA bigot through and through (typed on ppc64le!), to this day I still have an enduring sweet spot for Hewlett-Packard's PA-RISC "Precision Architecture" because it was my first job out of college. It doesn't hurt that it was one of the saner RISCs, with a fairly clean instruction set except for its odd deficiency with atomics, and was quite a piledriver in its day due to its cache arrangement and early adoption of SIMD. We ran HP-UX 10.20 on a big K250 where I developed database applications on Informix, later upgrading it to an L-class something or other (I think an L2000). When I was still consulting for the university one of my tasks was even setting up a Visualize C3750 workstation, which was a stupid fast machine at the time and I'm sure served very well for them doing protein visualization. Heck, if Commodore had stuck around longer, we might really have had a PA-RISC Amiga instead of the modern third-party PowerPC systems. (I've got some other wacky PA-RISC machines around here I might introduce you to later.)

The university only used the big stuff, though, not "low end" pizzaboxen like the versatile and (relatively) ubiquitous 9000/712 "Gecko," which besides being a popular 1990's RISC workstation of its own — id Software had one during their NeXTSTEP days — turned up as the system base in other surprising places. One of these was HP's own Agilent 16505A protocol analyser, and another was as the basis of the MIL-SPEC SAIC Galaxy portable workstations.

That dovetailed nicely with one of my major collecting specialties, which is non-x86 portables — I'm not just talking PowerBooks and ARM here, friends, and we'll explore some of those machines at a later time as well. But because these machines were often in classified or high-security environments, few escaped to the outside world and my current verified count of existing machines is just five, including my own. I managed to acquire a broken (like, literally fractured) Galaxy 1100 a number of years ago and tried gutting a 16505A to repair it but never got it past the boot screen, so when a working one turned up in March 2019 I jumped on it. This unit, which only required a minor amount of case repair, got refurbished with a SCSI2SD and a fresh installation of the PA-RISC port of NeXTSTEP 3.3, and runs it splendidly.

In fact, you've already briefly met this machine: it's one of the test boxes for Crypto Ancienne, which can bolt TLS 1.3 onto OmniWeb, NeXTSTEP's primary browser, and was one of the first articles I wrote for this blog trying to figure out how to get a screenshot from its video port. Some of you may have even met it in person when it was a (popular) exhibit for Vintage Computer Festival 2019.

But now I've managed to land a second working unit, and comparing their original hard drives has been an interesting dive into the security bowels of the U.S. federal government (especially since these units can actually boot them, unlike my dead Apple Network Server prototype from Netscape/AOL). Plus, it seemed like a good opportunity to talk in more detail about their internals and their history, take a tour of HP-UX and HP VUE prior to the "one ring to rule them all" of the Common Desktop Environment, and what this 16-pound tank of a portable workstation was actually used for ... and why you should always clear your cache on a secure system lest someone like me find the hard disk decades later.

Before all that, though, a droll tale from the military-industrial complex.

In 1982, the United States Chief of Naval Operations sponsored the Desk-Top Computer (DTC) program to provide a common fleet standard for "tactical decision support"; at some unspecified point the acronym evolved specifically to "Desktop Tactical Computer." For cost reasons the CNO chose an off-the-shelf system rather than demanding TEMPEST and MIL-SPEC compliance. While the Hewlett-Packard 9836U and 9020A systems were initially selected, the HP 9020C (also known as the 9000 Model 520C, based on an 18MHz FOCUS CPU) won out and became widely deployed. DTC-1 was the first of the U. S. Navy's several deployments of Hewlett-Packard microcomputers. Although the subsequent DTC-2 deployment used Sun-4 hardware, the Navy returned to HP for what was renamed the "Tactical Advanced Computer" with TAC-3, selecting the HP Apollo 400 series.

In 1993, the Navy issued a solicitation for the newest iteration of TAC, TAC-4, intended as "the next generation of computer workstations, software, support services and logistics in support of Naval requirements, afloat and ashore. It will provide the 'common engine' for mission and mission support applications, tactical, and non-tactical." Despite simultaneous proposals from Sun and Digital, HP landed the contract again for an estimated US$672.6 million (about US$1.39 billion in 2023 dollars), the largest HP ever handled to that point, which included hardware and software deployment for multiple operating environments along with upgrading the existing TAC-3 machines. HP filled this need with their up-and-coming PA-RISC hardware, in particular the 9000/712 workstation as a desktop client along with other 9000/700 machines like the /743i, /744 and later the J210, gradually moving to more conventional PCs and Intel servers as the multi-year contract progressed. TAC-4 was a big deal to HP and the effort was hardly secret; HP even printed up large stickers like these, and TAC-4 branding was also part of the operating system as we'll show. (Dig the International Code of Signals flags for Tango Alfa Charlie, though that combination of flags doesn't mean anything in ICS.)

A project this big inevitably required partners, such as Harris Corporation, who provided security software and network support for TAC-4's IT infrastructure. Another part of TAC-4 was delivering a portable MIL-SPEC ruggedized system for more hostile working environments, something HP didn't have in their product line. For this work HP subcontracted with Science Applications International Corporation (SAIC), then based out of San Diego and the dominant provider of tactical portable workstations for the Department of Defense. SAIC already had extensive experience with making tough hardware, most notably their RSC-1X, a reworked SPARC-based RDI BriteLite armoured in a metal shell and a pressurizable outer case made of steel.

This particular machine didn't need to be that tough, but it needed to be tough enough: the Navy specified FED-STD-101C, Method 5007.1, requiring it to survive multiple 30" drops onto concrete of each of its faces without structural damage. There was no TEMPEST certification requirement; it looks like the Navy was primarily interested in a computer that could simply take some punishment. It also had to be quiet enough (MIL-STD-740/1, Table 1 Class C), portable enough and self-contained enough so that someone could pull it out of a supply closet, plunk it on a table, plug in network and power and immediately have a fully-functioning computer. And that was the SAIC Galaxy.

The SAIC Galaxy family consisted of two systems, the 1000 and the 1100. Both the 1000 and 1100 were essentially recased 9000/712 workstations with minor hardware modifications and custom added electronics, but all of the systems I've seen including mine are Galaxy 1100s, based on an 80MHz PA-7100LC (the 1000 reportedly ran the 60MHz version).

Here's a closeup on the identification plate, placed on top with the keyboard.

The systems, for being big off-white plastic bricks, are surprisingly ergonomic. People at VCF raved about the 10.4" LCD screen, which is impressively bright, sharp and colourful (especially for 1994), supporting up to 1024x768. The keyboard is full-size with decent travel, and SAIC thoughtfully included easy-clean soft-touch wrist support pads with buttons on either side of the trackball for whatever handedness you require. Since ships inevitably deal with water, a keyboard overlay made it at least partially resistant to spills and splashes, though I have only one of them. A clasp in the front locks the lid shut when closed.

If the tracking numbers are at all sequential, my original machine on top is the older one, though nothing seems to have a date of manufacture or assembly printed on it except the hard disk and some of the chips (and these may have been replacements). Also note the "shipboard shock hazard," betraying its raison d'être.

The machines could absolutely be used as "conventional" workstations with the lid closed and connected to external devices. Closing the lid does not power it off or sleep the system. Switches in the back select the internal keyboard and trackball supported by modifications to the 712's logic board, or you could attach a PS/2 keyboard and mouse. Headset output and two audio inputs, DE-9 RS-232 serial, VGA, parallel, SCSI and Ethernet (AUI or twisted-pair) complete the port selection.

The outer case is entirely impact-resistant plastic. In this view, the rear with ports is facing north and the front with the power switch and 3.5" floppy drive is facing south. The bottom is elevated off the ground on rubber feet and by the cross-hatched pattern of ridges both for ventilation and if it got placed on a wet surface. Towards the front are three bolts arranged in a right triangle and four screws to the right of that in a vertical rectangle. These restrain the floppy drive and hard drive respectively.

The two front corners have long lag bolts that connect into shrouded screw holes; the front centre holds a smaller, shorter bolt. With these removed, the keyboard lifts up to reveal the interior. We see the underside of the keyboard and trackball, plus the power supply, the logic board, the accessory cards and the floppy drive bolted on top of the SCSI hard disk. While the inside isn't particularly packed efficiently, it's also easy to access all the components and effect field repairs, which would seem more important than any modest savings in interior volume.

The underside of the keyboard and, at the top, the trackball. The board is dominated by a large Datel DC/DC converter, ribbon cables for the matrix and power lines. The "danger" warning isn't kidding: when I was working on the unit with A/C power connected, I accidentally contacted the energized power supply below it and got a nasty if fortunately minor shock. Always use one hand when working on a potentially live circuit.

The power supply itself is the standard HP 0950-2356 (APS-61) 70W supply manufactured by Sony, the same power supply in the 9000/712, providing 3.3V, 5V and 12V DC. It accepts 100-240V AC without adjustment, which was by no means guaranteed on all computers in the mid 1990s. The main power block goes to a small custom interposer board that not only redirects the logic board's power pin headers 90 degrees for space savings but also bleeds off lines to power the keyboard and run the main fan instead of using the logic board's fan connector. The power LED and hard disk activity LED are at the bottom left next to the power button.

The logic board is a modified 9000/712 A2877A 80MHz system board. The red, white, blue and orange wire bundle runs from the keyboard and trackball, through the rear input device switches in series which act as cutoffs, and to solder points on the back of the logic board. The brown wires and the gauze-covered fabric ribbon go through the display hinge to the LCD, which we'll talk about when we get to the expansion slots.

The 80MHz PA-7100LC processor is under the blue metal heatsink; the crystal south of that serves as the main system oscillator, a 160MHz part divided down by 2 for the CPU clock. The PA-7100LC is a 2-way superscalar core that supports MAX-1 SIMD and has two integer units and one floating point with a five-stage pipeline. The CPU directly attaches to the bus and has its own onboard memory controller (MIOC). PA-RISC systems are unusual for supporting multiple levels of L1 cache, and sometimes of massive size: here, the PA-7100LC has 1K internally that prefetches from an additional 256K of directly attached direct-mapped external L1 to the left of it. On top of that, unlike most processors, the PA-RISC cache is physically tagged but virtually indexed. The 60MHz board has just 64K of external L1 which hobbled the slower board even more than the clock speed would suggest, and although the PA-7100LC is one of the minority of PA-RISC processors that could support L2 cache, the /712 logic board has no provision for it.

There are only four RAM slots on the 60MHz and 80MHz boards which take 72-pin 60ns FPM ECC SIMMs up to 32MB, so the limit is 128MB. Memory must be installed in pairs from the front going back; this machine has two 16MB sticks for 32MB of RAM, but my NeXTSTEP system has four 32MB sticks for the maximum 128MB. 64MB SIMMs exist but are not known to exceed the logic board maximum (the 100MHz variant can take six sticks for a ceiling of 192MB, but SAIC never used that board).

Also identifiable are the Western Digital WD37C65C floppy disk controller (dated 35th week 1995), the Crystal CS4125 16-bit "Harmony" audio chip (1st week 1996), a Fil-Mag 78Z1120D-01 10BaseT interface (35th week 1995) and a Maxim MAX211 RS-232 serial transceiver (1st week 1996). Both my units have version 2.2 ROMs which seems comparatively recent. Not visible here are the Intel 82C596CA 10Mbit Ethernet controller, the HP 1FT1 LASI ("LAN SCSI") ASIC containing the NCR 53C710 Fast & Narrow SCSI-2 controller as well as the system bus logic, and the HP 1FU2 CRX Artist onboard graphics ASIC with 1MB of VRAM, all on the underside of the board.

At the bottom of the board are the power connector, the SCSI pin header (the cable isn't keyed, so watch out), the speaker cable (red/black wires), the fan connector (unused on the Galaxys), and the floppy disk pin header. This is a regular 34-pin PC floppy disk connector, though it needs a twisted floppy disk cable to properly select the single disk as drive 0. You don't need the floppy connected to run the system, which makes it a bit easier to work with if you're just slinging SCSI disks. Both hard disks were Seagate Hawk ST32151N 5400rpm SCSI-2 "narrow" (i.e., 50-pin) drives.

The Galaxy has a weird expansion setup layered on top of the /712's already oddball selection of slots. The LASI ASIC implements the GSC (General System Connect) bus typical of other PA-RISC workstations of this generation, but that's where the similarities end. Instead of the more common 100-pin slots on other GSC systems, the 9000/712 has an 80-pin slot called GIO (General I/O?) intended for video, network and HP-IB options, and a 30-pin "Teleshare" or TSIO (Teleshare I/O?) slot that supported only a single card implementing telephony and fax/data modem functionality.

The GIO slot in the Galaxy is occupied by a second graphics card, a custom SAIC job which looks like a second CRX Artist card to the operating system and uses the same HP 1FU2 ASIC. It carries 2MB of VRAM on the card, same as the on-board Artist graphics (the A2263-66520/A4025A VRAM card installed in front of the SAIC graphics board upgrades the on-board graphics to 2MB). 2MB Artists support up to 1280x1024 with 8-bit colour enhanced by HP Color Recovery, which uses a special DSP to implement a 24-bit visual in hardware with minimal dither artifacts.

Although the SAIC Artist card may have been derived from it, this card is definitely not the same as the A2878-90010/A2878A second monitor card. Unlike the A2878A, which cannot act as the console, the SAIC card not only can but does so by default because it, not the onboard Artist, drives the LCD (and some of the LCD video hardware is on the card as well). This yields the atypical situation where the built-in display is actually the secondary one; the primary display is in fact the external VGA connector which is always available. As there are two Artists in the Galaxy, it can support dual displays.

The other oddity about the SAIC Artist card is what it's connected to. The Galaxy's official expansion slots are actually PCMCIA, though I only know of a 14.4Kbps fax modem card developed for these slots and I've never personally seen it. The PCMCIA slots are implemented by another SAIC-specific card bolted to the back of the SAIC Artist that looks like a GSC Wax EISA bridge to the machine — such as what you'd find in an HP 9000/745 — but the versions of HP-UX 10.10 that came with these systems actually have a module to support it and call it a "Cirrus PCMCIA Adapter" (the notation "Chip Rev. 05H" also appears in the kernel messages). The SAIC Cirrus card is notionally in the TSIO slot but jumpers on the SAIC Artist card, which specify if the Artist card is alone or "W/WAX-EISA" connected, suggest that Cirrus is at least partially dependent on the Artist card for function and possibly uses some of its bus lines (the card even calls itself "GSC WAX-EISA" instead of TSIO). Since legacy pre-CardBus PC Cards are implemented as EISA, the Cirrus board uses the same Texas Instruments TACT84500 EISA bridge chip as the regular HP Wax bus bridge.

When powering it on, the power LED flashes until it enters the kernel and starts flashing again when it returns from it (letting you know it's safe to power off). The boot screen on my "big" 128MB NeXTSTEP Galaxy looks like this, taken with an Inogeni VGA2USB3 capture device connected to the external video. I set it to 640x480 because this is the only 60Hz mode the Artist supports and the VGA2USB3 doesn't like other refresh rates. If you press ESCAPE here, you'll go to the boot monitor.

Displaying hardware info. Notice the console path is graphics. If it were set to the internal display, the console path would be graphics1. Again, this was not supported with the official HP second monitor card.

Showing the video options. The internal display is amusingly called "optional" and has a 62Hz refresh rate.

It's time to start the operating system.

SAIC HP-UX 10.10

Both of my machines came to me with HP-UX 10.10; what was loaded on top of that is, of course, the current topic of interest. Naturally they can run Linux or NetBSD, but where's the fun in that? They'll run 10.20 fine, 11.00 badly, not least because of its larger size (you'd want at least the full 128MB of RAM), and 11i past v1 not at all. It's possible later kernels don't support Cirrus, but unless you have and require the SAIC PCMCIA modem card, that's undoubtedly no perceptible loss — NeXTSTEP doesn't support it either. However, it's also notable that neither of these systems have any later version of HP-UX installed despite the length of time they were apparently in service (10.20 came out in September 1996).

There is no evidence that the Galaxys were ever sold commercially outside of their HP subcontract, though obviously some made it to the outside world like these units here, presumably through surplus resellers or scrappers and the like. That said, the most recent addition to my collection wasn't a TAC-4 system but rather vanilla HP-UX 10.10 with SAIC custom branding. We'll call this our "civilian" machine.

The reseller I bought it from said they couldn't break into it and thus were selling it as is (and knocked 25% off as an enticement). We can change the root password by bringing the kernel up single-user, but this particular machine surprisingly has an older version of the HP-UX Initial System Loader (ISL), specifically version A.00.25 dated November 10, 1992, and I think the different syntax it requires threw off the seller. We bring up ISL from the boot monitor with boot primary isl instead of just boot primary (here abbreviated to bo pri isl) and ordinarily would then give ISL the hpux -is command, but this version of ISL also needs you to specify where the kernel is (hpux -is /stand/vmunix).

I did a little exploration while the machine was in single user. The BR2325 lithium battery had of course gone to the great recycling bin in the sky, so it was getting the time from the filesystem, and here time had stopped at 12:18pm, January 26, 2001, U.S. Eastern Standard time. Other than my reboot and the reseller fruitlessly bouncing it up and down, the last console login was root at 6:10am on the same date. That appears to be the last time this machine was legitimately powered on in its prior life.

Other than root, the only other user account with a password (there's no shadow password in this version of HP-UX) was an account jpo (short for jpoco, in the GECOS field) with a home directory /usr/jpo (not in /home). There were relatively few files here and only the default .profile (the user's shell was Korn shell) and graphical login setup, but .sh_history had some interesting stuff like

PS1=YOUR ORDER, YOUR HIGHNESS
ECHO
echo $PS1
PS1=xxxxx
PS1="Your order, your highness"
PS1=$
PS1=Your order, your highness
PS1="Your order "

which seems like someone was playing around with the box, but later on there's more serious stuff like

mv ./tic cols
ll
cols
pwd
./cols
env
man PATH
cat /etc/default/login
find / -name default 2>/dev/null
cat /etc/default
cat /usr/newconfig/etc/default
/usr/newconfig/tcb/files/auth/system/default
cols
pwd
vi autopvcs

which seems more consistent with developer work. None of these commands are of course timestamped. This user's last login in wtmp was April 17, 2000.

uname said

# uname -a
HP-UX laptop01 B.10.10 A 9000/712 2008790574 two-user license

revealing its hostname as the supremely unoriginal laptop01, if your lap is the size of André the Giant's. But that wasn't its first host name, because there was also leftover mail to root from the system in /mbox and /var/mail/root, both timestamped January 1, 2000, and the mailboxes detail at least some portion of its history. On January 20, 1997, it was in the U.S. Pacific timezone named master and had a class A IPv4 address starting with 15.*, which at the time was entirely Hewlett-Packard's range. On February 24, 1997, its hostname was changed to mygal and it was given a nonsense address 123.45.67.8. On March 11, 1997, it was relocated to the Eastern timezone and renamed laptop01, but configured as "a standalone system" without a network address. That notification was the last mail message to root.

jpo had some mail, too, but only for a few days in February 2000. Among other things,

From jpo@laptop01 Mon Feb  7 05:19:24 EST 2000
Received: by laptop01
        (1.39.111.2/16.2) id AA011208764; Mon, 7 Feb 2000 05:19:24 -0500
Date: Mon, 7 Feb 2000 05:19:24 -0500
From: jpo@laptop01
Return-Path: <jpo@laptop01>
Apparently-To: jpo@laptop01

  ###
   #
   #
   #
   #
   #
  ###

#       ####### #     # #######
#       #     # #     # #
#       #     # #     # #
#       #     # #     # #####
#       #     #  #   #  #
#       #     #   # #   #
####### #######    #    #######

######  #     # ####### #     #
#     # #     #    #    #     #
#     # #     #    #    #     #
######  #     #    #    #######
#   #   #     #    #    #     #
#    #  #     #    #    #     #
#     #  #####     #    #     #

I'm going to assume these were test messages, but if they weren't, I hope they were very happy together. Other than similar messages and one piece of bounced mail, that was it. There was nothing past February 7, 2000.

I blanked out the root password and brought it up multi-user.

(I'll note here for veracity that I've cheated slightly to get these images, though I'm accurately relating the steps I truly took at the time. The screenshots were actually acquired slightly later after I properly configured the system and logged in as root over Telnet, setting DISPLAY to :0.0 and retracing my steps taking grabs off the framebuffer with xwd -screen -root. Yes, it will even let you do that of the login screen. For the present purposes of the story, kindly pay no attention to the man behind the curtain.)

Those of you experienced with legacy proprietary Unixes and older hardware might think this is just an oddball Common Desktop Environment (CDE) login, but it's not, and it's not just the SAIC branding either. Instead, this is CDE's immediate ancestor, the HP Visual User Environment (VUE). The version we'll be using is 3.0, the final version of HP VUE initially introduced with HP-UX 9.0. My HP-UX 8.0 9000/350 runs VUE 2.0, the original VUE release for HP-UX and an upgraded port of VUE 1.0 that ran on Apollo Domain/OS after HP acquired them. HP-UX 10.20 in 1996 was the last version of HP-UX to ship with the HP Visual User Environment (VUE) as an option and the first to support CDE, three years after HP, IBM, Sun and Unix System Laboratories agreed to cease hostilities in the "Unix Wars" and develop a common user interface to battle their mutual enemy Microsoft.

The visual similarities are no accident: CDE was directly descended from VUE, itself based on Motif and the Motif Window Manager (mwm), so CDE also became based on Motif. While the other parties contributed various components to CDE, HP VUE had the most impact on the user experience; even the configuration files were similar enough such that HP could offer a largely automatic migration tool to convert them. We'll point out some of the (mostly minor) interface differences as we go along.

Like the CDE login screen, vuelogin gives you a selection of session types. You can restart the server (the window server), use a text-only login, display copyright messages, log into a minimal fail-safe session with mwm and a single terminal console window (I'll show this later), a HP VUE Lite session or a full HP VUE session. You can also pick from any of the installed languages.

VUE Lite is a modest trimming of the core, featuring "enhanced system performance by omitting full icon-based file management, full session management, and file annotation" (per the 3.0 manual). I found little performance difference between the two on this system, but machines that are even slower or with comparatively more constrained RAM may see a positive improvement.

The copyright messages spill over the screen to the bottom and are the same as you get logging in (proof momentarily). Fortunately you can just press RETURN/ENTER if the OK button is no longer visible.

The Help button displays an explanation of the options with a mildly unprofessional typo. My wife the English teacher has volunteered her proofreading services to Hewlett-Packard for a highly reasonable hourly rate. We'll let you know.

Well, let's log in.

The VUE copyright messages, the same sort of screen you'd see logging into a CDE session, and exactly the same as the malproportioned window's.

The root account was not pristine; the previous user (jpo?) had it set up to launch a terminal window instead of the default "Welcome" help document. CDE's session management also hails from VUE.

The most obvious difference, however, is the front panel. Out of the box I find VUE's more functional than CDE's: not only do you have six default workspace shortcuts ("One" through "Six") instead of CDE's default four, as well as the same clock, mail, style manager, printer, filer, trash, app drawer and help shortcuts, you also have a CPU load indicator and dedicated shortcuts for managing the workspaces or opening a terminal window or text editor. And those are things you do a lot. HP's badging is a little gratuitous but we'll grant them the indulgence (it just gives you an about box if you click on it).

Our first order of business will be to get the network up, and for that we'll need SAM, the Software Automatic Mouth for your Commodore 64 computer HP System Administration Manager. Like "smit happens" in IBM AIX, and Solaris back in the day had admintool, HP-UX has sam. While you can do these tasks at the command line, sam certainly does make them easier to discover.

sam, like smit, has both graphical and text shells. The graphical shell integrates well with VUE with icons and windows, rather better than the AIXwindows variant of smit which just has little menu buttons to press.

There is also a substantial amount of interactive on-line help.

As a demonstration, we'll look at the graphic options first. I mentioned that there are functionally two Artist graphics adapters installed, so it has two displays. VUE is only set up to use the LCD and the second display is greyed out.

When an object is selected, you can perform actions on it. VUE supports multi-screen and "single logical screen" (spanned desktop) configurations. We don't have a second display connected to this but it's nice to have the option.

Let's see what's installed.

Not a great deal over the base installation, it turns out. There are modem, fax and telecom programs onboard, but those would need an external modem since there's none in the PCMCIA slots. The Cirrus support modules are listed here as well as a diagnostics kit, support for LIF (HP Logical Interchange Format) volumes, and Ghostscript. For some reason the window isn't resizeable.

Note that this doesn't list anything "sideloaded," of course. For example:

# ls /opt
audio          graphics       nettladm       upgrade
dce            ifor           screencapture  video
dcelocal       image          sharedprint

Among other things, this system also has an image viewer, audio support for Harmony and display drivers, as well as OS support for the Distributed Computing Environment, the remote procedure call mechanism HP inherited from Apollo when it bought them out and became part of the collective vendor efforts behind OSF/1. Ironically, DCE primarily survives today in the form of Microsoft Distributed COM (via MSRPC).

The /opt/video directory is particularly interesting as it's a remnant piece of HP MPower, intended as a collabourative environment for VUE that supported scanning and faxing images and documents, shared X clients and whiteboarding, and working with video, audio and images. It doesn't seem to be configured on this system, though, and the only pieces of MPower present are the audio editor (which doesn't work), the screen capture tool and the image viewer. HP decommissioned it with HP-UX 11i and it was only supported on certain workstations and HP X terminals, but the strings in /opt/video/lbin/vlServer still have my favourite system message ever: "No Problem, Dudes and Dudettes"

Now for networking, so we can remotely log in (like we already are to take the screenshots, he says under his breath) and also fix the clock over NTP from Floodgap's local stratum-1 server.

After setting a local IP address, we need to configure the Name Service Switch. Notice that HP-UX by default really wants to be under YP/NIS (odd that this is still the case on an ostensibly "standalone" system), so we'll just put everything under local control and cut NIS out entirely.

This is a great example of how well thought out SAM can be. Specifying search order and behaviour is just a matter of several select boxes.

Now for NTP.

If at any time you're not sure what's going on, you can ask SAM to "explain" it to you (here we've asked it to "Explain NTP"). Rather than pause here to reboot or otherwise forcibly update the clock, though, let's exit SAM and continue with our brief tour of VUE.

The default layout for VUE opens a help window "Welcome to Your HP Workstation!" which contains hypertext documentation. Help files are directly accessed from tools in a help subpanel which rises out of the front panel (including a special man page viewer), in the same way as the later CDE front panel does. Here I give CDE points because you just click the same arrow to open or retract the various subpanels; VUE requires you to press the "down" arrow on the subpanel itself to retract it. Subpanels are windows and can be moved around the screen. They regain their default location when you retract them, even if you moved them. You can configure their underlying description files in /etc/vue/config/panels.

While the help facility isn't unlike what we saw in Sun's OpenWindows functionally (which was PostScript-powered), obviously it most resembles CDE's help system visually. The VUE 3.0 Help Viewer was indeed accepted "almost as is" (in HP's words) as part of CDE.

However, what it views changed radically. CDE help documents start as SGML files using a DTD called HelpTag, and are then "compiled" into another SGML-based distribution format called Semantic Delivery Language (SDL, confusingly to modern audiences), the chief difference being that Semantic Delivery Language is optimized for more efficient display. An SDL "runtime help file" breaks up sections and chapters from HelpTag source into blocks and forms, merging them with various style sheets ("tables of semantics and styles," or TOSS) into a collection of self-contained virtual pages with no external dependencies other than images. Applications distribute a single .sdl file, plus any graphics. A list of identifiers (LOIDS) in the runtime help file serves as the index.

So VUE was just an earlier version of that scheme, right? Well, no. Let's look at this very same help "document" itself as displayed by the Help Viewer in /usr/vue/bin/helpview. In fact, it's several files:

# cd /usr/vue/help/C/Vueintro
# ls -l
total 232
-r--r--r--   1 bin      bin         5967 Nov 18  1995 Vueintro.hv
-r--r--r--   1 bin      bin         2822 Nov 18  1995 Vueintro.hvk
-r--r--r--   1 bin      bin        45206 Nov 18  1995 Vueintro00.ht
dr-xr-xr-x   2 bin      bin         1024 Feb 24  1997 graphics
-r--r--r--   1 bin      bin         6644 Nov 18  1995 rVueintro.hv
-r--r--r--   1 bin      bin         2822 Nov 18  1995 rVueintro.hvk
-r--r--r--   1 bin      bin        51552 Nov 18  1995 rVueintro00.ht
# ls graphics
DT-icons.pm     VIctrStyMgr.pm  VIminHlpMgr.pm  helpmgr.pm      sampleicon.pm
VIctrDskJet.pm  VIctrSubPnl.pm  VIminStyMgr.pm  hplogo.xwd      subpanel.pm
VIctrDtMenu.pm  VIctrWmMinz.pm  VIminToolbx.pm  info.pm         sysadmin.pm
VIctrFax.pm     VIf1Key.pm      VIminWmIcon.pm  minifm.xwd      tools.pm
VIctrFilMgr.pm  VIminDtIcon.pm  VImseClick.pm   minifp.xwd      tour.pm
VIctrLjet2.pm   VIminFilMgr.pm  VImseDrag.pm    miniicons.xwd   users.pm
VIctrLjet3.pm   VIminFrPan2.pm  exit.pm         miniterm.xwd    welcome.xwd
VIctrMktPla.pm  VIminFrPanl.pm  help-mgr.pm     password.pm     wspic.tif

Vueintro is presented to non-superusers; a special administrator-specific rVueintro is presented to root, which is what we see here. The .hv "Help Viewer" files define the topic list, topic hierarchy (what identifier is a topic's parent, or nothing for the top-level), and then a directory matching topics to the .ht file containing them and the byte offset within it. A keyword-topic index resides in the .hvk file. As for the graphics, they're all XPM (.pm), XWD (such as the "Welcome to Your HP Workstation!" text, which is actually an image), or TIFF (the nice artsy graphic, which is pre-dithered).

That's all straightforward enough, but the .ht file itself is mostly opaque binary other than the inexplicable text <TOPIC charset iso8859-1></TOPIC>. binwalk couldn't make head nor tail out of it. That solitary tag suggests some sort of SGML-based format, but nobody knows, apparently not even Hewlett-Packard themselves: HP in the 8/96 Hewlett-Packard Journal admitted that the "distribution format [for VUE 3.0] was known only within HP and then only by some members of one division. The specification of this distribution format was never published or intended for publication." They also considered the need for multiple files to be a liability (NARRATOR: It was.), "resulting in problems such as losing one or more of the files during installation." Oops.

The two other default subpanels are for printers and toolboxes. Remember when HP made printers that were good? HP VUE remembers. There are three printer targets ("Default" plus a Laserjet III and Deskjet) pre-installed. The items in the toolboxes subpanel open Program Manager-like windows to select installed applications.

The Personal toolbox draws from tools in the user's home directory (the default set here is provided from /usr/newconfig if none exist); General consists of the applications pre-installed on the machine. Network lets you run VUE actions on remote machines you have access to via DCE RPC, but naturally no such machines are present, and Marketplace was invariably empty since no upstream products are available.

The style manager (visual preferences) tool, on the other hand, came to CDE almost entirely intact. Anyone who's used CDE will be hard pressed to tell the difference.

The file manager and the (sub?)toolboxes in the General toolbox. Again, the influence on CDE is patently obvious.

Quite possibly the most interesting application (which should still work in CDE, but HP stopped including it with HP-UX 11) is xhpcalc, a triple-mode simulation of the HP-11C, HP-12C and HP-16C calculators. There are of course many HP calculator simulators, including ones from HP themselves, but this is the true original and officially authorized by Hewlett-Packard. Alas, there is no source code, but I have a real Voyager HP-15C anyway.

HP also included a simple date book, and there were various "unsupported" applications including this Columns game. I appear to have been the first one to actually play it on this computer because the high score list was totally blank.

Logging out, almost exactly the same alert CDE would give you on exit.

Before we leave for the SCIF to try TAC-4, though, let's take a brief look at HP VUE Lite.

HP VUE Lite's most obvious difference is a modified front panel. There are only four default workspaces and the system load, printers, file manager and trash can are all absent.

In addition, the only tools you have are the ones in your Personal tool box and the terminal window shortcut has moved to a subpanel of its own with a rather large range of terminal session options, even if their differences might be practically subtle. You could of course run any apps you wanted from a shell prompt; they're just not part of the interface.

On the whole, though, on even this modest 80MHz 32MB system I could detect no perceivable difference other than marginally faster startup. Near as I can determine VUE Lite wasn't even considered to be part of CDE and thus disappeared when VUE did.

TAC-4

That's enough background for us to move to the TAC-4 hard disk. Before we continue, let's get a couple things straight, especially since right now no one in the federal government can apparently handle classified information properly: nothing I'm going to show here has any known classification level, not even Controlled Unclassified Information, Sensitive But Unclassified or For Official Use Only, none of which are technically classified anyway. I myself carry a federal security clearance because $DAYJOB and I don't care to jeopardize it.

That said, I was also not able to find anything on the hard disk that appears to be classified in any case. Most likely such materials resided on a central server, which we'll show how we know this machine to have accessed. I will intentionally not provide IP addresses or certain unrelated FQDNs in case portions are still operational, but we can derive what the machine was used for, and as the purpose it served is already known openly I see no issue with talking about it here.

Like the "civilian" install we'll boot single user to get into the filesystem, but the A.00.38 October 26, 1994 version of ISL on this hard disk will use the default path to the kernel if one is not specified.

In single user I blanked the root password and took a look around. Its clock stopped at May 19, 1998, 4:08pm Eastern Daylight Time (last verifiable login was April 29, 1998, at 6:24am). There were no other users with a password other than root. The root user had no shell history, and only a default .profile and VUE configuration, but had run Netscape. We'll come back to this.

uname was exactly the same as the civilian installation except for the hostname (which was taped to the front; I've removed it):

# uname -a
HP-UX osfhp03 B.10.10 A 9000/712 2008790574 two-user license

This machine was named osfhp03. The derivation of the HP part is obvious (I suppose there were at least three in this location), but not sure what OSF meant (Operational Support Facility?) except that it probably didn't mean OSF/1.

There was nothing in /home and nothing in /usr that looked like an orphaned home directory, but there was an odd directory /h:

# ls -a /h
.           AcctGrps    CompT       GZIP        SAMBA       h.tar
..          COE         DAZ         JETADM      USERS       public
APACHE      COTS        EM          PrtDrivers  data

The h.tar looked like it was sideloaded here from some other system and suggests it enabled server functions (given Apache, Jet Admin and Samba), though we don't know if this machine actually ran those, of course.

The COE directory is also noteworthy. This appears to be compliant with The Open Group's Common Operating Environment and at that time minimally required Perl and Netscape Navigator (on this system 5.003 and 4.04 respectively) along with a webserver (Apache). There is also a JVM installation and Tcl along with other components. COTS even had a PA-RISC version of Adobe Acrobat Reader 3. The USERS directory contained various profiles including for the web server and for anonymous FTP. The most recent file was date-stamped April 20, 1998.

I'm going to tell this story in the "right" order without cheating now that you've seen the basic interface. When I restarted and tried to enter VUE the machine put up the copyright message, but after an interminable wait stalled out with this fatal error:

My guess is it was waiting for network resources which never arrived. We'll need to cut the ties that bound it, and for that we'll bring up SAM in text mode this time.

Text SAM has the same menu options as VUE SAM and works "the same" — you just get around with keystrokes instead. HP console terminal emulation is really great, actually, and much better than the console on my AIX hardware.

Untangling the Name Service Switch.

Its DNS settings, though, are worth talking about. I've obliterated the nameserver IP but I want you to see the default domain, adnet.smil.mil.

Don't bother trying to resolve that from your home desktop because you can't. Broadly speaking, in a United States Department of Defense facility that handles sensitive or classified information, different classification levels live on different, separated networks as part of the overarching Defense Information System Network (DISN). Top Secret material and/or Sensitive Compartmented Information uses the DoD's Joint Worldwide Intelligence Communications System, or JWICS, and virtually any DoD SCIF will be connected to it. On the other hand, unclassified information travels on the Non-classified Internet Protocol Router Network (NIPRNet), which replaced MILNET (separated from ARPANET in 1983) in the early 1990s, though anything on any of the other networks can also be unclassified.

For the Secret or Confidential information in the middle, that goes over either JWICS or the Secure Internet Protocol Router Network, or SIPRNet. SIPRNet is sort of a pocket parallel Internet universe with its own services like SIPRNet-specific websites and E-mail. Unclassified information can also be on SIPRNet, including on SIPRNet-only sites. The giveaway that this system was connected to SIPRNet is the .smil.mil part: that second-level domain is unique to SIPRNet. For the U.S. Department of State, which also uses SIPRNet, there's a corresponding .sgov.gov.

What about the adnet. part? Well, that alone tells us generally where this machine was used. ADNET, the Anti-Drug Network Program, came out of the Defense Authorization Act for Fiscal Year 1989 and the Defense Appropriations Act of 1990 directing the Secretary of Defense to create a communications network for U.S. assets involved in drug interdiction and counternarcotics, whether dedicated or partial, civilian or military. It provides real-time secure communications (including radio and satellite, not just over SIPRNet), data sharing and analysis capabilities. As early as 1991, 88 DoD and law enforcement systems at 59 sites were already connected throughout the Western Hemisphere and Europe according to a December 1991 U.S. General Accounting Office brief.

In 1991 ADNET's workstation view looked like this. Various, possibly purely illustrative, radar tracking snapshots and an unclassified opnote are displayed. The GAO report stated "[t]he system uses software modified from an existing Navy battle-management and command-and-control system." If this was indeed a U.S. Navy computer, then at that time it may have descended at least in part from TAC-3, the previous HP Apollo deployment. ADNET is an obscure initiative and small by American military budget standards, but its existence and purpose are hardly classified; the U.S. General Services Administration has even done press releases about it.

To have that default domain in its DNS settings means this system must have been on the inside. Unlike the more careless user of our civilian unit, however, there are no residual system E-mail boxes here to get the history and the same GAO brief also documents 27 possible locations in that timezone in multiple settings — I might add none of them matching the acronym OSF — so we can't get much more specific than the eastern United States. In /h/COTS/ADNET there are jobs to execute in cron and various client binaries, but they're just things like an audio and animation player, FTP client and log rotator, and there's no knowing if this machine ever even ran them. By 2015, from the most recent Defense Information Systems Agency budget I could cursorily locate, there were 45 core sites in ADNET but over a thousand connected devices.

I mentioned that the root user had run Netscape at some point and while they only had default settings and bookmarks and an empty mailbox, they didn't clear their browser cache. There was exactly one site in the cache called adnetdns, an unclassified resource, downloaded over SIPRNet. Here is how it appeared on April 27, 1998, at 9:26AM Eastern, authentically rendered in Netscape Navigator 4:

All URLs were in the .smil.mil second-level domain. I've suppressed the E-mail address and the phone number because some of you are naughty and this is why we can't have nice things, but the page above appears to have been the internal DNS site at the time. (I didn't suppress the date; looks like someone forgot a preprocessing step before uploading the document.) This exact HTML document (with an .html.sed extension) and GIF image are also on disk under /h, but this machine was not adnetdns: assuming the DNS server this machine used was adnetdns, which the comment next to the entry in SAM apparently claims, their former IPs don't match.

Correspondingly, given its branding and identical operating system version, my best guess for what our civilian machine was doing was probably support for the (by then) legacy TAC-4 systems still in operation like this one. As such it was almost certainly used by SAIC themselves, probably out of or supervised by their Reston, Virginia office.

TAC-4 had its own branding for the VUE login screen, too.

Login options are the same.

Because the login controls are lower on the screen, though, the copyright message immediately spills over the bottom and takes the OK button with it. Just press RETURN/ENTER to make it go away.

Same help screen, same disfunctional proofreeder. We'll write up a proposal for the Navy too.

Okay, that's enough messing around; time to log in as root.

The TAC-4 copyright screen is almost exactly the same as the civilian build but adds, "Use and distribution of this software is restricted to the TAC4 procurement."

The last root VUE session came up like this, with a subpanel still open and a filer window pointing to the now-disconnected port1:/. There was of course nothing in it but this client appears to have depended on it. There's no way of knowing exactly what was there. We'll see this server again a little later.

By the way, dig the custom background. I've converted the entire XBM image to PNG so you can make your own desktop wallpaper look like you're using an old Navy computer too. You're welcome; I'm here to serve.

For all that branding, though, there wasn't any obvious customization done to the front panel itself. The default subpanel contents are unmodified and the Welcome help file is still the same.

Listing installed software in SAM is equally uninformative, though unlike the civilian machine someone actually kept somewhat current with updates. And, well, given that /h is basically a big wad of sideload, we shouldn't be surprised. There were some interesting TAC related things in the filesystem:

# ls /var/adm/sw/products
0200AC-core-pat   InstantIgnite     SOE               TAC4-powerchute
0200AC-supplmnt   International     SUPPORT-TOOLS     TAC4-xmcd
Accounting        InternetSrvcs     SW-DIST           TerminalMngr
AudioSubsystem    JournalFS         ScreenCapture     TextEditors
B3782DA           Keyshell          SecurityMon       TextFormatters
Curses-Color      LSSERV            SharedPrint       UUCP
DCE-Core          LVM               SourceControl     Upgrade
DCE-CoreTools     MSDOS-Utils       Spelling          VME-Services
DFS-Core          MailUtilities     Streams           VUE
DigitalVideo      NCSNCK            Streams-TIO       X11
DirectAccess      NFS               SystemAdmin       X11BMS
DiskQuota         Networking        SystemComm        eeprom-driver
Diskless          NonHP-Terminfo    TAC4-15-inch      fax-application
EMACS             OS-Core           TAC4-PDU          ifiles
GraphicsCommon    PHCO_6641         TAC4-XPAX         pcmcia-driver
GraphicsPEX5RT    PHKL_7615         TAC4-copyright    pcomm
HPUXEngRT700      PowerShade        TAC4-ghostscript  swlock
INDEX             PrinterMgmt       TAC4-lmgrd        xmodem
ImagingSubsystem  ProgSupport       TAC4-logo         zmodem

The TAC4-* packages are almost all standard utilities and it's noteworthy they were explicitly TAC-branded. I really don't know why a CD player (xmcd) or Ghostscript or license manager (lmgrd) needs to be tagged TAC-4, or even be part of it for that matter, but we'll assume they were defined portions of the overlay. Most of them deposited things in /opt:

# ls -a /opt
.              dce            ifor           sharedprint    xpax
..             dcelocal       image          upgrade
TAC4           emacs          nettladm       video
audio          graphics       screencapture  xmcd
# ls -ldt /opt/TAC4     
drwxr-x--x   2 root     sys         1024 Sep 19  1996 /opt/TAC4
# ls -alR /opt/TAC4     
total 8
drwxr-x--x   2 root     sys         1024 Sep 19  1996 .
dr-xr-xr-x  17 bin      bin         1024 Sep 19  1996 ..
-rw-r-----   1 root     sys         1185 Jul 19  1996 tac4-copyright

And yes, all it is is the copyright file, exactly the same text as VUE displays on login.

These packages seem to have come from the mysterious server port1. We know this because /.sw/sessions/swinstall.last has an entry for its tape drive (swinstall.source_tape = port1:/dev/rmt/c0t3d0BEST). Very likely that machine served multiple clients, this unit being only one of many.

I couldn't find anything on the machine that looked like it could have generated the GAO brief's screenshot, though. This machine might not have run it or it might have been obsolete by then.

Logging out.

VUE Lite wasn't customized at all for TAC-4, it appears. It only had the default session and didn't even get the cool embossed wallpaper treatment.

I mentioned the fail-safe session in VUE, so here it is for completeness. It's literally just Motif Window Manager and a terminal window, but hey, you can do everything from mwm and a terminal window. This would have been handy for a small-disk workstation with few local resources, but this TAC-4 client was "fat," and I imagine this session type was rarely used even in emergencies.

Shutting down.

What have we learned? We know that in 1997 the Navy announced the new IT-21 "Information Technology for the 21st Century" program to succeed TAC-4, intended to replace the older TAC-3 and DTC-series systems that were still in service. By then the desktop PC had won out as commodity hardware and the RISC warhorses were sent to pasture. This TAC-4 system seems to have been end-of-lifed in 1998 consistent with that timeline; combine this with the chip dates and it looks it was in service for only around two years. It would make sense that the SAIC support systems remained in place until the last TAC-4s were gone, which based on the civilian system's clock looks like around 2001, and so that was the lifetime of the initiative.

Second, we've also learned that whatever software magic there was to TAC-4, it either wasn't local or didn't exist. The observable software packages are almost all off the shelf. It would seem strange to selectively remove classified packages without taking the usual "nuke it from orbit" approach, so I think we're on solid ground concluding what we saw is what they got. I like these computers rather a lot and I have no doubt the Galaxys acquitted themselves well in their unique environments, but TAC-4 seems to have been virtually all about selling hardware, which the American military-industrial complex is all about too, and the desktop experience was therefore tarted up only as much as it needed to be to look "special." (And third, some of you got to learn about a DoD program you'd never heard of before.)

But there are some larger lessons as well. First off, assuming there really was any effort made to scrub the hard disk, items were still missed that could tell us a lot from a little, and it's fortunate for the Department of Defense this ended up with someone who knows how to handle classified material (unlike some Presidential administrations I could mention). But they get some opsec credit for apparently keeping nothing actually classified on the system itself, even though it might have been better just to shred the disk and surplus the rest — though if they did that I wouldn't have been able to write most of this article.

This is probably some of the last software environments we'll be able to preserve from settings like these, by the way. The Feds move slow, but security gadgets get budgets, and 20 years from now all we'll see are SSDs encrypted at rest if we get any hardware at all. High-security retrocomputing will thus become an entertaining exercise in finding back doors — or just plain brute force.