I don't know that I had a single "Aha!" moment, but there were a few
things that just got hold of me and led me down the Unix path...
The first Unix I used was V7m on a PDP-11/40, in college. By this point,
I was "aware" of Unix, in theory I even knew C - but never had an actual
system to try it out on until this point. I'd used other operating
systems (or things that called themselves operating systems...), primarily
TRSDOS, CP/M, OS1100, TOPS-10, TOPS-20, and VMS. Unix was certainly the
first multiuser operating system that I ever had administrator access on.
1) The idea of taking the output of one program, and using it directly as
input to another program - and the simplicity by which it was done -
was revolutionary to me. It was not unusual for me at that time to do
things like this by having the first program create a temporary file,
and then having another program open this temporary file and use it as
input, but the whole paradigm of stdin/stdout/pipes made it so you
didn't even have to "know" in your program that you might need to use
the output of some other program (via a temporary file) as input.
That was amazing to me.
2) Unix was really the first operating system that I had full, buildable
sources for. (I theoretically had access to VMS source code, but it
was on microfiche and not in machine-readable form, so it was just a
read-only reference.) If I wanted to see how the OS was doing
something, I could look. If I wanted to change something the OS did,
or add something to the OS (either in the kernel, or as a user space
utility), I could do that (and I did on a couple of occasions). If
something was broken, I could try to figure it out and fix it. There
was this bug in V7m, where if you were on a non-separate I&D system
that didn't have the floating point option (and our 11/40 did not), and
you tried to run an "a.out" file that was zero length, you'd get a
kernel panic. We were using the system for a computer architecture
course, students were programming in assembly language, and if there
was a problem with the source file the assembler would leave a zero
length executable behind. Of course, students would try to run it
anyway, even though "as" produced errors. We'd sometimes get 3 or 4
system crashes in the course of an evening. The students and the
instructors were all up in arms because any time this would happen,
everyone would lose whatever they were working on (and maybe more, if
the filesystem got messed up during the panic), and if there was no one
around who had a key to the computer room when it happened, it would
stay down until they could find someone who had physical access and the
knowledge to know how to deal with "fsck"... (The construction in the
lab was pretty minimal, and the walls to most of the rooms didn't go
all the way to the ceiling - sometimes when it crashed and no one was
around, they'd take to climbing over the wall to reboot the system
themselves - which could produce disasterous results of there were
filesystem issues...) I found the problem, and I fixed it. That was
my first adventure in kernel debugging... (Later, we migrated to a
PDP-11/24 and we ordered the KEF11-A floating point option for it, so
that problem became moot.)
3) The idea of processes being able to talk to each other (without some
kind of pre-arrangement, like setting up a pipe between them, or
using temporary files) was just amazing, and this was the first time
I'd really seen it. I knew VMS had this thing called a "mailbox",
but I never used it for anything and didn't even know what it was
for. On V7m, I stumbled across the mpx(5) man page. I think the
first time I came across it, I stared at it for hours, looking at
the description and trying to figure out what you'd even use that
functionality for. At some point it was like a lightning bolt hit
me - "Oh, wait! You can use this to send messages between unrelated
processes!" Except V7m came with one little proviso - the mpx code
was there, but it didn't work... So I dug into it, and made it work -
at least, well enough for what I wanted to use it for. I wrote a
multiuser chat program with it (isn't that the first thing any
undergrad does when they discover interprocess communications? :-) ).
I had a similar epiphany with sockets on 4.2BSD a year or two later,
under similar circumstances. The one thing I found in command with
both mpx and sockets was that the documentation described the
low-level functionality - but there was nothing that clearly stated,
"This functionaliy is used to allow processes to talk to each other"...
I'm sure there are plenty more experiences with early Unix that ensured
that I'd continue down this path, but I think these are my favorites.
--Pat.
Possibly the most time consuming install I did was installing Xenix on a
bunch of Intel i310 systems. Xenix was a "secondary" OS for these
systems, the main OS being iRMX. Xenix for these systems was distributed
on 5.25" floppies. Lots and lots of floppies... They came in a 3-ring
binder, many pages of floppies... We also had a couple of i380 systems,
Xenix for those came on 8" floppies... That was time consuming, but it
was just manual labor.
The most unpleasasnt install I can recall was AIX 2.2.1 on the IBM-PC/RT.
Which also was really (under the covers) Interactive UNIX, with some other
stuff mixed in. Not only was this also time-consuming with a binder full
of 5.25" floppies, but my recollection is that there were too many
opportunities to make a tiny little mistake during the install and have to
start all over again.
--Pat.
Apropos of Steve Johnson's evocative description of JCL and other
pre-Unix OS interfaces, doing legwork for Multics I ran the following
experiment on a lot of then-current time-sharing systems.
As a model of creating and installing a new compiler, I used a very
short Fortran program that simply copied its input to its output,
stopping after finding END in column 7 of the input. The drill was
compile the program
run it, using its own source as input
compile the freshly made output file
This failed on every system I tried it on, though local
experts could intervene with magic to overcome the
gratuitous file-type distinctions that typically
got in the way. Dartmouth's DTSS came closest, but
inexplicably, even to the gurus, it had a special
prohibition against a program reading the source
from which it was compiled.
Incidentally, my favorite manifestation of JCL-like mumbo jumbo
was the ironically named FUTIL control card in GECOS.
Doug
> From: Doug McIlroy
> doing legwork for Multics I ran the following experiment on a lot of
> then-current time-sharing systems.
Fascinating; you don't happen to remember the ones you tried, do you?
Also, when you say "legwork for Multics", was this something done during
the planning stages (so, say '64-'65), or later on?
Noel
I wrote a UNIX shell based on Python the other night in case anyone's
interested: https://github.com/terrycojones/daudin Apologies for a modern
instead of an historic subject...
Terry
