January 9, 2020

Unix Before Unix

Although I started writing this blog last October, I intentionally waited until January 1, 2020, the 50th anniversary of the Unix epoch, to start putting it online. I’m a Unix person, and a big anniversary like that was too good to pass up. (That, and I’m so lazy it took me three months to set up a web server.)

The story of Unix is a lovely story that’s been told many times, by people more skilled at storytelling than I am, many of whom were there to see it, some of whom did it. So I’m not going to retell it here. There’s plenty of stuff to read up on at TUHS if you want to learn more.

For all the talk about Unix starting a revolution, it was really an evolutionary step, building on the results of the previous decade of operating system development. Don’t take my word for it, take Dennis Ritchie’s:

In most ways UNIX is a very conservative system. Only a handful of its ideas are genuinely new. In fact, a good case can be made that it is in essence a modern implementation of MIT’s CTSS system. This claim is intended as a compliment to both UNIX and CTSS.

You heard the man, let’s take a look at CTSS, shall we?

CTSS is relatively obscure today - though compared to Unix and Windows, every operating system is relatively obscure. It never ran on more than two computers at once, both of which were at MIT. It was written mostly in assembly language for three successive models of the IBM 709x architecture (the 709, 7090, and 7094), which were top-of-the-line mainframes for scientific computing when development started in 1961, but obsolete relics by the time it ended in 1969.

The name stood for the Compatible Time-Sharing System. Time-sharing meant a single computer could support multiple simultaneous users, each of whom interacted with it on their own terminal - a revolutionary concept at the time, when the only way to interact with most computers was to drop off a deck of punched cards and wait a few hours for the operators to run your job and hand you back the printed results. It was compatible in that existing users with batch jobs in decks of punched cards could still run them the old way too.

I see CTSS as the first “real” operating system, to which all later ones owe something significant. This is, as with all firsts, a matter of controversy. In particular, the Brits have a case that the Supervisor on the Manchester Atlas was the first “real” OS. But looking at the documentation on the Atlas, it’s clear they were solving a different problem. The Atlas had a multiprocessing batch OS, capable of handling 16 separate batch jobs at once, but had no methods of interaction. Impressive, to be sure. Others at MIT and BBN had simultaneously written time-sharing systems for the PDP-1, the original minicomputer. MIT system, written by and for the original “hackers” at RLE, relied on punched paper tape for data storage and had an arcane debugger-based interface. The BBN system I’ve found precious little information about, though John McCarthy was involved so it had to be pretty good.

But you look at the first CTSS paper - that’s a command line! In 1962, when everyone else was still dealing with punched cards and paper tape! When I look at earlier systems, it takes me a while to get into the proper state of mind to figure out how they were used and translate them into more modern concepts. CTSS has a few archaisms, but I bet if you sat me down with the CTSS Programmer’s Guide I’d get the hang of it pretty quickly.

And the manual, if you flip to the back section of the second edition to where the commands are described - those are man pages! CTSS was used for early Multics development by what would become the Unix team, and the influence is obvious. And the commands themselves - ARCHIV is clearly the inspiration for ar and tar, and some of the single-letter options haven’t changed since the ‘60s. From RUNOFF came nroff and troff. CTSS MAIL and Unix mail are both simple, file-based inter-user communication, down to the “From” lines that are why you can’t start an email with “From” even today. And as far as text editors go, QED looks a lot like ed, sharing many commands and the regex syntax. But of course it does. It was written by Ken Thompson, based on the same-named editor he used at Berkeley, after all.

But there wasn’t just a standard text editor, because there wasn’t a standard for “text.” Three character encodings were in use on CTSS: the six-bit native encoding of the 709x in all caps, a twelve-bit encoding that allowed for lowercase and some additional symbols, and seven-bit ASCII, which would’ve been the obvious choice to start with if it had existed in 1961, but it didn’t until 1963. They all had their own editors, and ad-hoc tools for converting among each other and “compressing” them into 36-bit words more efficiently.

File names were six characters long, in all-caps six-bit characters, because 36 bits. Files also had six-character “secondary names” or “types”, which functioned in the same way as extensions on later operating systems, including Unix. (I can hear the purists shouting now - “Unix doesn’t have extensions!” Funny, nobody told make about that.)

There was, originally, no “shell” in CTSS. The supervisor read commands directly from each terminal and executed them. Two later programs would lay the basis for Unix shells: RUNCOM, which took in a file of CTSS commands and ran them in sequence, and . SAVED, an advanced user interface on top of CTSS with a more advanced command language. There’s enough to talk about in these two programs for their own post, but suffice it to say they laid the groundwork for shell scripting and, oddly enough, instant messaging.

This post is already long enough, but there’s so much more to talk about, including the background behind CTSS and the technical details of how all this was implemented. And there were more Unix ideas that came from elsewhere, most notably the Project Genie time-sharing system, which gave us QED and inspired fork(), and Multics, the joint venture between the CTSS team at MIT and the future Unix team at Bell Labs, with its hierarchical directories and its shell deliberately designed as a programming language.

Unix itself had only a few new ideas, but made a lot out of a little. Ken and Dennis and company deserve a lot of credit, but they also took a lot from their predecessors.

© 2020 Bronx River Software

Powered by Hugo & Kiss.