Old Vintage Computing Research

I had this grand idea many moons ago about writing up a TCP/IP stack for the Commodore 64, along with a lot of other people, and several of those people eventually did so before I even wrote a single opcode of 6502 assembly. For that purpose I had bought the box set of TCP/IP Illustrated (what would now be called the first edition prior to the 2011 update) for a hundred-odd bucks on sale which has now sat on my bookshelf, encased in its original shrinkwrap, for at least twenty years. It would be fun to put up the 4.4BSD data structures poster it came with but that would require opening it.

Fortunately, today we have AI we have many more excellent and comprehensive documents on the subject, and more importantly, we've recently brought back up an oddball platform that doesn't have networking either: our DEC Professional 380 running the System V-based PRO/VENIX V2.0, which you met a couple articles back. The DEC Professionals are a notoriously incompatible member of the PDP-11 family and, short of DECnet (DECNA) support in its unique Professional Operating System, there's officially no other way you can get one on a network — let alone the modern Internet. Are we going to let that stop us?

Of course not! Here's our barebones network stack for PRO/VENIX, the Pro's only official Unix option, downloading the Google home page on real hardware (internal addresses bleeped out) over SLIP and a Crypto Ancienne proxy for TLS 1.3. And, as we'll discuss, if you can get this thing on the network, you can get almost anything on the network! Easily portable and painfully verbose source code is included.

In computing the DEC PDP-11 is something of a geologic feature. Plus, as most systems in the family were minicomputers, they had the whole monolith thing going for them too (minus murderous apes and sucking astronauts into hyperspace). Its fame is even more notable given that Digital Equipment Corporation was among the last major computer companies to introduce a 16-bit mini architecture, beaten by the IBM 1130 (1965), HP 2116A (1966), TI-960 (1969) and Data General Nova (1969) — itself a renegade offshoot of the "PDP-X" project which DEC president Ken Olsen didn't support and even cancelled in 1968 — leaving DEC to bring up the rear with the PDP-11/20 in 1970.

So it shouldn't be a surprise that DEC, admittedly like many fellow mini makers, was similarly retrograde when it officially entered the personal computer market in 1982. At least on paper the DEC Rainbow was reasonable enough: CP/M was still a thing and MS-DOS was just newly a thing, so Digital put an 8088 and a Z80 inside so it could run both. On the other hand, the DECmate II, ostensibly part of the venerable PDP-8 family, was mostly treated as a word processor and office machine; its operating system was somewhat crippled and various bugs hampered compatibility with earlier software. You could put a Z80 or an 8086 in it and run CP/M and MS-DOS (more or less), but it wasn't a PC, and its practical utility as a micro-PDP didn't fully match the promise.

However, what DEC did to the PDP-11 was odder still. The 1982 DEC Professional 350 had the same F-11 ("Fonz") CPU as the bigger PDP-11/23, though that's where the similarity ends, as it implemented a new bus with completely different option cards and an incompatible interrupt system making it all but impossible to run unmodified PDP-11 programs. It had really nice graphics for 1982, but instead of the usual choices its intended system software was the laughably named Professional Operating System, or P/OS — execrated for its sluggish menus and limited feature set, of which people were only too quick to make the obvious joke. You could get CPU option cards like the DECmate II's to also make it into a weak PC or a weak CP/M machine, but they ran through P/OS too, and they weren't cheap. At the same time, however, in order to be the most inexpensive PDP-11 system ever, the low-binned DEC Professional 325 didn't even have a hard disk.

All of these systems were originally meant as commodity machines for office work, yet more or less with the exception of the Rainbow, they couldn't run much that office professionals actually wanted to run and little that existing PDP users did. Still, despite questionable technical choices, these machines (the Pros in particular) are some of the most well-built computers of the era. Indeed, they must have sold in some quantity to justify the Pro getting another shot as a high end system. Here's the apex of the line, the 1984 DEC Professional 380.

The Pro 380 upgraded to the beefier J-11 ("Jaws") CPU from the PDP-11/73, running two to three times faster than the 325 and 350. It had faster RAM and came with more of it, and boasted quicker graphics with double the vertical resolution built right into the logic board. The 380 still has its faults, notably being two-thirds the speed of the 11/73 and having no cache, plus all of the 325/350's incompatibilities. Taken on its merits, though, it's a tank of a machine, a reasonably powerful workstation, and the most practical PDP-adjacent thing you can actually slap on a (large) desk.

This particular unit is one of the few artifacts I have left from a massive DEC haul almost twelve years ago. It runs PRO/VENIX, the only official DEC Unix option for the Pros, but in its less common final release (we'll talk about versions of Venix). I don't trust the clanky ST-506 hard drive anymore, so today we'll convert it to solid state and double its base RAM to make it even more professional, and then play around in VENIX some for a taste of old-school classic Unix — after, of course, some history.

Most of my systems are microcomputers (and commensurately sized), though I do have some moderately larger beasts: you've met homer, my 1987 HP 9000/350 rack system, and Floodgap is powered by uppsala, a 2U-in-a-tower IBM POWER6 520 running AIX. But my first "large" machine, and indeed the first Unix server I ever personally owned, was this Apple Network Server 500. Its name is stockholm. A mini-fridge-sized server with its famous translucent blinkenlight-friendly front sliding door and oodles of drive trays, this $11,000+ box (almost $22,000 in 2023 dollars) sat forlorn and unused at the University I was employed with as an IT working stiff in 1997. The bookstore had bought it at a substantial academic discount for their UniVerse-based (a Pick descendant, now Rocket U2) point-of-sale system, but the vendor wouldn't support the hardware anymore after then-CEO Gil Amelio cancelled the ANS line, so it got dumped off as surplus in the service bay where it lurked in a corner. As it was just sitting around, I got to use it as my personal server, shown here circa 1998 in my old office on a bad scan from a bad Polaroid. In this picture it's acting as a terminal server for my Commodore SX-64 with a CMD SwiftLink 6551 ACIA serial cartridge (the SX-64 is sitting on a parallel port switchbox because its handle got busted).

About a year later the University said they'd throw it in with my consultant compensation because they wanted to get rid of it anyway, so it became officially mine, and I was delighted to have it. That machine, later upgraded to 200MHz and 512MB of parity FPM RAM, variously powered my E-mail and the Floodgap gopher and webservers from 2000 to 2012, and still does backup duty when the POWER6 has to be down for repairs.

That's because the POWER6 runs everything the ANS did — because the ANS also runs AIX. The ANS 500 and 700 were not Apple's first Unix-specific servers (that would be the Apple Workgroup Server 95, a Quadra 950 using a special PDS card that only worked with A/UX, Apple's own Unix with a bolted-on Mac compatibility layer), but they were Apple's first Mac derivatives that could not boot classic Mac OS at all and natively ran a non-Apple operating system. Indeed, most people treated it as exactly that, a big Unix server from Apple, and at the time I did too.

However, there was a secret weapon hidden in ANS AIX most of us at the time never knew about. Built-in to the operating system was a fully Unix-native AppleTalk stack and support for receiving and sending Apple Events, surfaced in the form of Apple's disk administration tools and AppleShare. But Apple had a much more expansive vision for this feature: full server-client "symbiotic" applications that could do their number-crunching on the ANS and present the results on a desktop Mac. Using the Program-to-Program Communication Toolbox ("PPCToolbox"), and because AIX's throughput far exceeded anything the classic Mac OS ever could ever handle, an ANS could augment a whole bunch of Macs at once that didn't have to stop to do the work themselves.

Well, today we're going to write one of those "symbiotic" applications doing something this little Mystic Color Classic could never efficiently do itself — accessing and processing a JSON API over TLS 1.3 — and demonstrate not only how such an client application looked on the Mac side, but also how the server component worked on the AIX side. If you're lucky enough to have an ANS running AIX too, you can even compile and run it yourself. But before we do that, it might be a little instructive to talk about how the Apple Network Server came to run AIX in the first place.

I've previously mentioned Solbourne Computer, which for a number of years was probably Sun's most significant early competitor in SPARC-based systems. Solbourne was the first to market in 1989 with multiprocessing SPARC servers based on their custom circuit-switched 108MB/s KBus interconnect, running a bespoke but highly compatible licensed SunOS 4.x clone named OS/MP; later, they even developed their own SPARC CPU, the benighted MN10501 "KAP" Kick-Ass Processor (yes, really). At least one Solbourne system even went on the Space Shuttle. Sun didn't have multiprocessor SPARCs until 1991 with the competing MBus-based Sun-4m systems.

My own affinity for them started when I had an account on a Series6 for a few months as an undergraduate college student and a few years later ended up with my own pizzabox S4000DX. I still have that machine, but my usual Sol is an S3000 portable workstation with that lovely garish gas plasma screen simply because it's so incredibly unique. In 1990, when this presentation slide was made, the sky seemed bright and the foundation seemed solid.

But by March 1992, cracks were showing, and now we have a view into that process then — a rare inside glimpse at the hardware development and executive management of a 1990s tech company. In a shipment of various Solbourne paraphernalia, a former employee from late in the company's dying days sent me a couple VHS tapes of corporate meetings. One of them will need some cleaning and rehabilitation, but the other was in good condition and absolutely playable, and I was able to digitize it on the Power Mac G5 Quad with my trusty Canopus ADVC-300. These are second-generation copies and the quality is worse than usual, but they tell the story adequately and serve as a fascinating time capsule of the company's later doom and nineties-era enterprise computing generally.

As threatened we're up to the next checkpoint with Crypto Ancienne, the TLS 1.2/1.3 library we maintain for pre-C99 vintage compilers and architectures, so here's version 2.2, or "Crypto Ancienne Meets the Hooded Fang" (read about previous releases).

New checkpoints are always an opportunity for new ports. Why am I showing you a picture of my Amiga Technologies A4000T? Because AmigaOS 3.9 is one of them!

It's time for another Crypto Ancienne checkpoint, which will be a post Real Soon Now(tm), including some new operating system frontiers. But part of the work for Cryanc is all the build regression testing on the supported platforms: each of the platforms I vouch for has to be able to compile the updated source code and use carl, its built-in mini-curl clone (officially the "useful" demonstration application), to successfully and completely download from a selection of real websites. One of these is harlan (named for Harlan Anderson, co-founder of Digital Equipment Corporation), my one and only DEC Alpha-based machine, a DEC AlphaPC 164LX running Digital UNIX Tru64.

The DEC Alpha is a good test for Crypto Ancienne because it's a fast (for the time) and finicky (for all time) RISC architecture, with notoriously strict alignment requirements and an extremely loose memory model. Early Alpha CPUs in fact entirely lacked instructions for direct short or byte access — 32-bit, 64-bit or bust. Unfortunately the Ethernet card blew while I was testing Cryanc 2.0 and I couldn't validate that version, so I just pushed that checkpoint out the door. Well, we can't do that two releases in a row, darn it. I have a replacement NIC and a mission. It's time for a Refurb Weekend.

In the post on our recently resurrected fork of Dreamcast Linux, I mentioned the NetBSD NFS server providing basically all of its persistent storage. A few days into the development work I started hearing a weird whine coming from the server room and sure enough the NFS server had a bad fan — in fact, the only fan cooling the entire 1U system. That means it's time ... for another Refurb Weekend!

Yes, here at Old VCR we live in the past, when RISC Unix workstations still ruled the earth like large boxy tentaculous Cthulhus. Oh, sure, if you wanted a modern equivalent you could just buy a Raptor POWER9 like the one I'm typing on now. But around here even PowerPC is too pedestrian of an architecture. We need something unique. That's more like it! A keyboard, mouse, a NIC, VGA output, 16MB of RAM and a whole gig (you wish) of read-only optical drive space with a 200MHz Hitachi SuperH SH-4 CPU faulting its paltry 8K of I-cache and 16K of D-cache non-stop. Now freshly refurbished, its cooling fan runs louder than my Power Mac Quad G5 at idle and the drive makes more disk seeking noise than when I can't find a lost floppy. And since the buzzword with Linux distros today is immutability, what could be more immutable than an ephemeral, desperately undersized RAM disk overlaid on a live CD?

Did a few updates to the Solbourne Solace thanks to new stuff people have sent in, Solbourne of course being one of Sun's most notable competitors in SPARC-based workstations and servers. The most interesting new entry is the space-faring PILOT ("Portable In-flight Landing Operations Trainer") laptop, reported by Scott Manley who noted it in Space Shuttle mission photographs. While the SPARC Solbourne S3000 portable workstation is well-known, this was the only known Solbourne laptop and its only colour portable, although it carried both Solbourne and Panasonic badges (Matsushita, owner of the Panasonic brand, had a majority stake in Solbourne), and was most likely designed and manufactured by Matsushita's Federal Systems division under contract instead of Solbourne in Longmont, Colorado. NASA commissioned it as a portable simulator to ensure that the Space Shuttle commander and pilot could maintain their skills in orbit, and it flew at least from October 1993 to March 1995 (the pictures above are from STS-62 and STS-63; it was documented on STS-58, -61, -62, -63, -65 and -67).

The machine had 32MB of RAM, a 15" colour LCD and a dedicated "Rotational Hand Controller." The software was NASA's own Shuttle Engineering Simulator (SES), ported to SPARC from the Control Data Corporation Cyber 180 Model 962 (an upgraded version of the RISC Cyber 180-960) at the Johnson Space Center in Houston, Texas, and ran on OS/MP 4.1A, Solbourne's equivalent of SunOS 4.1.1. Its motherboard was most likely a Solbourne "pizzabox" IDT logic board, the same one used in the S3000, S4000 and S4100 which directly competed with O.G. SPARCstations, making the reported speed of 40MHz suspect since the Panasonic MN10501 KAP (short for "Kick-Ass Processor" — yes, really) was notoriously unstable above 36MHz. A suspiciously similar laptop called the Matsushita P2100 was announced in 1992 but by then Sun was making moves to freeze SPARC clone makers out of the market, particularly Solbourne who had cornerned the more profitable upper tiers, and refused to license Solaris to anyone like they did SunOS. (Apple later pulled this same stunt with the Mac clones and Mac OS 8.) The P2100 doesn't seem to have been ever released, and while a few PILOT examples were likely fabricated, no one so far has found one. PILOT was eventually replaced by various IBM ThinkPads which went on to have a well-known and illustrious career in space.

A big thanks to Warner Losh and Dieter Dworkin Müller for the probable scoop on PILOT, as well as Scott's own research and his initial report, and this unofficial NASA description from 1994.

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.

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.

Computers are hot. No, I mean, they're hot. They heat our house in the winter here in primarily sunny Southern California (not as much as my wife would like, but that's another story for another day).

Previously we talked about monitoring the portable air conditioning unit keeping the server room cool. The SMS gateway, basically an overgrown Raspberry Pi, uses a USB decibel meter to report ambient noise volume in the room, from which we can extrapolate the state of the air conditioner's compressor and fan. The Sawtooth Power Mac G4 file server (and radio station) logs the temperature and humidity with a USB sensor of its own. The portable A/C unit exhausts warm air through a duct to the roof so the room can remain secure, and a turbine spins the hot air away into the atmosphere.

Unfortunately, what all this monitoring showed was the A/C unit was crapping out. The house central A/C's compressor died abruptly this summer after over two decades, naturally during the hottest part of the year, and it took nearly a week and $14,000 to get it dealt with (it was an old R-22 system and thus everything had to be replaced). The portable A/C was itself almost 11 years old by this time, and after that bad week running nearly non-stop started making an ominous unbalanced low warble from its exhaust fan. This got to the point where it was unable to clear its own condensate and a couple days where I had to empty the drain pan about every 12 hours, versus never having to before (not a great deal of humidity here). I like old computers, but I try not to accumulate old broken computers, and that goes double for old broken air conditioners. It was time for a replacement.

Who says you can't teach an old box new tricks? We did it before and we're doing it again. Crypto Ancienne ("Cryanc") is a TLS implementation for pre-C99 beasts and monstrosities featuring carl, a simple curl-like utility that serves as a demonstration command line tool and even as an HTTPS-over-HTTP proxy for suitably configurable browsers. Many operating systems are supported and a number of compilers too (not only gcc going back to version 2.5 and the egcs days, but also clang, MIPSpro, Compaq C and even Metrowerks CodeWarrior). Now, after a lot of late night hacking, screaming and unspeakable acts of programming, tons of bugs are fixed (including a long-standing big-endian issue with ChaCha20Poly1305) and the core has been significantly upgraded such that almost all of the supported platforms now support TLS 1.3.

And what are those supported platforms? Why, here's some of them as they were being cruelly whipped to perform like beaten dogs for your entertainment:

We're house hunting because of $JOB and $HOUR hour commute, and I just got word that the reseller I contract with for Floodgap's leased line is getting out of that business in mid-January. This makes finding new digs (or at least setting up some sort of temporary static IP alternative) a must because one of the gotta-haves is space for my vintage server room. Sure, you can outsource, or host things on slices, or put things on a rack of Raspberry Pis and call it a day. And admittedly that would probably take up less space, generate less heat, use less power and result in less inconvenience, but where's the fun in that when you can be running your own 2008-vintage IBM POWER6 for mail, web and gopher, or a Sawtooth Power Mac G4 file server, or a 1989 Mac IIci that still happily handles internal network DNS?

Apple's announcement of the next version of macOS, Monterey, means my 2014 MacBook Air now gets to join my Quad G5 in the "not supported" category (not that I care, it's Mojave Forever). But it's a good reminder of the previous Project Monterey, a multicorporation attempt to make the One Unix To Bind Them All from IBM AIX, SCO (then the putative holders of the True Unix) and DYNIX/ptx that would run on the One Architecture To Bind Them All, IA-64 (a/k/a Itanium). In case you weren't yet with the new hotness, it would run on your old and busted 32-bit x86 hardware, too.

Today you'd laugh your fool head off at the very thought of "Itanic" taking over the world, but when it was announced in October 1998 Monterey was a credible threat. By having IBM, SCO, Sequent (which IBM bought) and Intel as backers its ascent to dominance seemed inevitable, and its ability to run on existing and future hardware along with the jackboots of AIX and the multiprocessing strength of Dynix was thought to be strongly appealing to high-end enterprise IT. (The issue of IBM's then-contemporary POWER server line and Intel's Pentium server offerings potentially in direct competition was handwaved away.) A long list of the usual hangers-on backed it at the time as well, including Acer, Compaq, Groupe Bull, Samsung and Unisys.

The damn thing actually shipped, too, because most of it was based on already extant code. Project Monterey's first release was to essentially repackage AIX on POWER, and UnixWare 7 and DYNIX/ptx on x86; in 2000 the next wave and the "real" Project Monterey was AIX 5L for IA-64, which IBM actually sold on request and apparently had some small number of running systems in the wild.

Oddly, what doomed Project Monterey was Linux on IA-64, the so-called "Trillian Project" that emerged in mid-1999. Intel, always one to hedge its bets, was part of that effort along with Silicon Graphics, VA Linux and Hewlett-Packard, but most of the work was done by Cygnus before their eventual purchase by Red Hat. SGI and HP, of course, made their own Itanium machines; HP, to its current chagrin, still does. As if in response IBM promised Monterey would have strong Linux compatibility, but if you needed Linux compatibility as a primary feature, why not just run Linux? A Caldera executive was quoted in InfoWorld that year saying, "I would expect over the next one to two years [Linux for IA-64] will catch up and in some cases exceed Monterey, for no other reason than the sheer number of people contributing to Linux."

And, well, that's exactly what happened; Itanium outlasted Monterey, and Monterey went down in flames. IBM sold less than 50 licenses by the time Monterey was quietly shot in the head in 2003, though some sources say IBM had already pulled out as early as 2001. Its breakdown directly led to the SCO vs IBM lawsuit in which SCO went bankrupt and in a related case was found never to have had the Unix license to grant to IBM in the first place. Itanium, for its part, will cease shipments a little over a month from now on July 29, 2021.

Somehow I just don't see this Monterey being that interesting.

The TLS apocalypse knocked a lot of our fun old machines off the Web despite most of them having enough horsepower for basic crypto because none of the browsers they run support modern protocols. Even for Mac OS X, the earliest version you can effectively use for Web browsing is 10.4 because no earlier version has a browser that natively supports TLS 1.2, and for most other old Un*ces and the like you can simply forget it.

To date, other than the safe haven of Gopherspace, people trying to solve this problem have generally done so in two ways:

• A second system that does the TLS access for them, subsuming the access as part of a special URL. As a bonus some of these also render the page and send it back as a clickable image; probably the best known is Web Rendering Proxy which works on pretty much any browser that can manage basic forms and imagemaps. Despite the name, however, it is accessed as a special web server rather than as an HTTP proxy, so links and pages also have to be rewritten to preserve the illusion.

• A second system that man-in-the-middles a connection using its own certificate authority; the request is then upgraded. Squid offers this feature, and can act either transparently or as an explicit HTTP proxy. Modern browsers defeat this with certificate pinning, but these browsers wouldn't have that, though you do need to add the proxy as a CA root.

The man-in-the-middle step is needed because most old browsers that are SSL or TLS aware don't want the proxy messing with the connection (it's supposed to be secure, dammit), so they open up a raw socket with CONNECT to the desired site such that all the proxy should do is merely move data back and forth. I imagine it is eminently possible on today's fast systems that an SSLv2 or SSLv3 connection's symmetric key could be broken by brute force by a transparent proxy and used to decrypt the stream, then re-encrypt it to modern standards and pass it on, though I couldn't find a public package obviously like that. (If you know of one, post it in the comments.)

There is a third alternative, however: configure the browser to send unencrypted HTTPS requests to an HTTP proxy. Most browsers don't do this because it's obviously insecure, and none do it out of the box, but some can be taught to. What you want is a browser that doesn't speak HTTPS itself but allows you to define an "arbitrary protocol" (with "finger quotes") to use an HTTP proxy for, and come up with an HTTP proxy on the back end that can accept these requests. Such browsers exist and are even well-known; we will look at a few.

But let's do one better: all these approaches above need a second system. We would like whatever functional layer we have to bolt on to run on the client itself. This is a retrocomputing blog, after all, and it should be able to do this work without cheating.

To that end allow me to introduce Crypto Ancienne, a TLS 1.2 library for the "Internet of Old Things" with pre-C99 compatibility for geriatic architectures and operating systems. What's more, Cryanc includes a demonstration application called carl (a desperate pun on curl) which, besides acting as a command-line agent, is exactly this sort of proxy. You can build it, have it listen with inetd or a small daemon system like micro_inetd, and point your tweaked browser's settings at it. If it's listening on localhost, then no one can intercept it either. Et voila: you just added current TLS to an ancient browser, and you didn't even burst any wineskins.

The browser that allows this nearly perfectly and with fairly good functionality is the venerable OmniWeb, prior to version 4.2. Although the weak HTTPS of the era can be added to OmniWeb with a plugin, and later versions even included it (I'll discuss that momentarily), it is not a core component of the browser and the browser can run without it. OmniWeb started on NeXTSTEP as a commercial product (it's now available for free); version 2.7 ran on all the platforms that NeXTSTEP 3.3 supported including 68K, Intel, SPARC and HP PA-RISC. We have such a system here, an SAIC Galaxy 1100 named astro, which is a portable ruggedized HP Gecko 9000/712 with an 80MHz PA-7100LC CPU and 128MB RAM.

carl builds unmodified on NeXTSTEP 3.3 (cc -O3 -o carl carl.c); the C compiler is actually a modified gcc 2.5. micro_inetd.c just needs a tweak to change socklen_t sz; to size_t sz; and then cc -O3 -o micro_inetd micro_inetd.c. Then we need to configure OmniWeb:

You will notice that we are running carl via micro_inetd on port 8765 in the terminal window at the bottom; the command you'd use, depending on where the binaries are, is something like micro_inetd 8765 carl -p (the -p puts carl into proxy mode). The URL we will use is thus http://localhost:8765/, though note that micro_inetd actually listens on all interfaces, so don't run this on an externally facing system without changes. We have assigned both http and https protocols to that proxy URL and OmniWeb simply assumes that https is a new and different protocol that the proxy will translate for it, which is exactly the behaviour we want. Let's test it on Captain Solo Hacker News: Excellent! Self-hosted TLS on our own system! Let's try Lobste.rs! OmniWeb 2.7 doesn't support CSS or JavaScript, and its SGML-to-RTF renderer (!) is not super quick on an 80MHz computer, but it's remarkable how much actually does work and it's even somewhat useable.

What about later versions? As most readers already know, NeXTSTEP 3.3 became OpenSTEP 4.0 (dropping PA-RISC, boo hiss), and then after Apple bought NeXT, or possibly the other way around, became Rhapsody 5.0. Rhapsody was a curious mixture of a not-quite-faithful facsimile Mac Platinum interface and OpenSTEP underpinnings and was eventually a dead end for reasons we'll mention, but Apple did turn it into a saleable product, i.e., the original Mac OS X Server. OmniWeb 3 runs on Rhapsody, and of course we have such a system here, the best laptop to run Rhapsody on: a PowerBook G3 WallStreet II "PDQ" named (what else?) wally with a 292MHz G3 and 384MB of RAM.

We built carl and micro_inetd on wally in the same way; its cc is actually a cloaked gcc 2.7.2.1. Configuring OmniWeb 3 is a little trickier, however:

You'll notice the non-proxied destinations and protocols are off. When these were on, it seemed to get confused, so you should disable both of them unless you know what you're doing. Again, note the terminal window in the background running carl via micro_inetd with the same command, so the URL is once again http://localhost:8765/, and both http and https are assigned to it. You can see Lobste.rs was already working but here it is without the settings window in the way: And here's Hacker News: There is still no CSS, but there is some modest improvement in the SGML rendering, and the G3 rips right along. I actually rather like Rhapsody; too bad not much natively runs in it.

Rhapsody was a dead end, as I mentioned: for the Mac OS X Public Beta, Apple instead introduced the new Aqua UI and made other significant changes such that many Rhapsody applications weren't compatible, even though they were both based on early releases of Darwin. Nevertheless, the Omni Group ported OmniWeb to the new platform as well and christened it OmniWeb 4. OmniWeb 4 was both better and worse than OmniWeb 3: it has a much more capable renderer, and even does some CSS and JavaScript, but it is dreadfully slow on some pages such that the 600MHz iMac G3 I ran it on seemed significantly slower than the Wally which ran at less than half the clock speed. In version 4.2 OmniWeb started using the system proxy settings instead of its own (ruining our little trick), and with the availability of Apple WebCore with Safari in Mac OS X Jaguar 10.2 a new and much faster OmniWeb 4.5 came out based on it. If it weren't for the fact I was already a heavy Camino user by that time I probably would have been using it too.

This leaves us with 4.0 as the last OmniWeb we can use carl for, but 4.0 was written for Cheetah 10.0 specifically and seems to have issues resolving domain names beyond Puma 10.1. Not a problem, though, because carl can do that work for it! Here we are working on christopher, a tray-loader strawberry iMac with a 600MHz Sonnet HARMONi G3 upgrade card and 512MB RAM running 10.2.8.

The Omni Group still kindly offers 4.0.6 for download. Drag the application from the disk image to /Applications, but before you run it, open the package in the Finder and go into Contents and Plugins. This is one of the releases that included HTTPS support, so drag HTTPS.plugin to the Trash, empty the Trash and start up the browser. Configuration is much the same as OmniWeb 3 but with one minor change:

Again, we have the Terminal open running micro_inetd and carl (it's actually running the binaries copied off wally!) on port 8765, but since OmniWeb 4 can't resolve domain names on 10.2, the URL is http://127.0.0.1:8765/. Non-proxied destinations and protocols are likewise off. With that, here's Hacker News: And here's Lobste.rs. The rendering improvements are obvious but so is the significantly increased amount of time to see them. By the way, if you're wondering where the window shadows are, that's because I run Shadowkiller on this iMac. Without it, its pathetic Rage Pro GPU would be brought to its knees in Jaguar.

So that's it for OmniWeb. What other browsers can we use for this? Surprisingly, an even more famous name: NCSA Mosaic!

NCSA Mosaic was available in multiple forms, including one also maintained by yours truly, Mosaic-CK, which descends from the last Un*x release (2.7b5) and the only NCSA browser for which the source code is known to survive. With the Mosaic-CK changes it builds fine on present-day macOS, Mac OS X, Linux and others. Like OmniWeb it treats HTTPS as a new and different protocol and you can tell Mosaic-CK to use a proxy to resolve it, so here's Mosaic-CK 2.7ck13 on my Raptor Talos II running Fedora 33 showing Hacker News.

You can set up the proxy rules with the interface, but it's simpler just to make a proxy file. If you run Mosaic-CK once, a preferences folder is created in ~/.mosaic (or ~/Library/Mosaic-CK for Mac). Quit Mosaic-CK and inside this folder, create a file named proxy like so:

https 127.0.0.1 8765 http
http 127.0.0.1 8765 http

Each line must end with a space before the linefeed. Then, with carl running as before, Mosaic-CK will access HTTPS sites through the proxy.

Naturally this doesn't extend the functionality of Fedora 33 very much though (especially since I'm typing this in Firefox on the very same machine), so what about systems that can run Mosaic-CK yet have no other options for modern TLS? One of those is the very operating system Mosaic-CK was originally created for, Tenon's Power MachTen.

Power MachTen is essentially OS X inside-out: instead of running Classic on top of a Mach kernel, Power MachTen and its 68K ancestor Professional MachTen run a Mach kernel on top of the classic Mac OS. I have it installed on bryan, my 1.8GHz Power Mac G4 MDD running Mac OS 9.2.2, which you earlier met when it chewed through another power supply (as MDDs do). Power MachTen has its own internal X server on which it runs AfterStep by default and includes Motif libraries. Here's the MDD viewing Hacker News; notice the classic Mac menu bar and the xterm running micro_inetd and carl.

However, even though Power MachTen uses gcc 2.8.1 and no modifications to the source code were required, some hosts consistently have issues. Lobste.rs, for example, throws a TLS alert 10 (unexpected message), and some other sites that appear to use a similar server stack do the same. Still, this is substantially more than OS 9 can do on its own. What if we moved this to a "real" Apple Unix -- A/UX?

Most readers will know what A/UX is, Apple's SVR2-based Unix for most 68K Macs with an FPU and MMU. It is notable in that it also includes System 7, allowing you to run both standard Mac apps of the day as well as compile and run binaries from the command line (or use the built-in X server), so we'll run it on spindler, a Quadra 800 clock-chipped to a 38MHz 68040 with 136MB of RAM running A/UX 3.1. There is a Mac version of NCSA Mosaic which for some reason uses a different version number, though the source code is apparently lost. It runs just fine in A/UX's Mac Finder, however, so we'll install NCSA Mosaic for Mac 3.0b4. Instead of the included Apple cc we'll use gcc 2.7.2, which is available from various Jagubox mirrors; carl builds unmodified and micro_inetd just needs the socklen_t fix.

3.0 is the only release of NCSA Mosaic that allows suitable proxy settings, at least on the Mac (2.x used "gateways" fixed to conventional protocols instead). We define http and https protocols, then point them both at localhost:8765 (use "Remote" so that you can fully specify the host and port). carl is already running under micro_inetd in the background (see the CommandShell window).

Here is 3.0b4 (trying to) displaying Google. I'd love to show you Hacker News, but it can't cope with the reflow and crashes. These crashes don't occur in Mosaic-CK, nor does the <script> spew; I don't know if the Windows version of Mosaic does this but I don't have a Windows port of carl currently. 3.0b4 also doesn't like getting HTTP/1.1 replies from servers that answer with /1.1 responses even to /1.0 requests. That's probably inappropriate behaviour for them but Mosaic doesn't even try to interpret the reply in those cases. The -s option to carl can fix this for some sites by spoofing /1.0 replies (though the headers are passed unchanged), but some sites won't work even with that.

So, since Mac Mosaic 3.0b4 is persnickety and crashy as heck, do we have an alternative that can be configured in the same way? Not the usual suspects, no: not Netscape, nor MSIE, nor NetShark, nor MacWeb. But incredibly, MacLynx works!

MacLynx is a port of Lynx 2.7 to 68K and PowerPC with (as befits Lynx) very light system requirements. The source code is available, though the binary I'm using here is monkeypatched to fix an issue with an inappropriate Accept-Encoding header it sends. Configuring it is very un-Mac-like: edit lynx.cfg and set http_proxy and https_proxy appropriately, as we are doing here in BBEdit 4.1.

Unfortunately MacLynx still has some other problems which will require a trip to the source code to fix, including not knowing what to do with text/html;charset=utf8 (so no Hacker News). Similarly, carl on A/UX has the exact same failures on the exact same sites in my internal test suite as it did on Power MachTen, which makes me wonder if something in Apple's lower level networking code is responsible (so no Lobste.rs either). But, hey, here's Google over TLS, and there's no script-spew! This problem doesn't occur with apps running in Classic under Mac OS X talking to carl running in the Terminal, by the way. That said, if you just want TLS 1.2 on Mac OS X Tiger, you could just run TenFourFox and even get TLS 1.3 as part of the deal.

Anyway, this entire exercise demonstrates that with a little care and the right browser you can bolt modern cryptography on and put at least some of these machines back to work. I'm planning to do further ports to IRIX (it builds already but MIPSPro c99 miscompiles some sections that need to be rewritten) and SunOS 4 (needs support for the old varargs.h), and I've got an AlphaPC 164LX running Tru64 here doing nothing as well. I'll have to think about what browser would be appropriate for IRIX other than Mosaic-CK, but Chimera runs nicely on SunOS 4 and the source code is available, and it doesn't need Motif (so it could even be an option for A/UX or older HP/UX). For classic Mac, MacLynx works very well already, so if we can fix its minor deficiencies and make it a little more Mac-like I think it will do even better on 68K systems in particular.

Of course, a still better idea would be to simply integrate native HTTPS support into those classic browsers for which we do have the source code using Crypto Ancienne itself rather than carl as a proxy. That's an obvious goal for a future release of Mosaic-CK.

And, well, maybe this is an opportunity to make Gemini appropriate for retrocomputing. A Gemini client becomes possible now that we have a TLS 1.2 client, and its lighter weight document format would be an especially appropriate choice for these machines. We could even bolt it onto these browsers here by defining a new protocol gemini:// for them and writing a proxy to translate Gemini to HTTP/1.0 and its document format to HTML; you could start with carl itself and make the appropriate modifications. Anyone feel like a weekend project?

Crypto Ancienne is available on Github.