It's been twenty years since I used it, but I still have fond memories of
the first real operating system I got to use. When I started in my first paid
job, back at the start of 1982 I accessed the VAX computers at work via a
physical VT100 – the console that modern command-line windows all emulate,
with varying degrees of added fanciness. This gave me twenty-five glorious
lines of text, each 80 characters long. I interacted with the computer it was
connected to by typing commands in DCL – the Digital command language; the
VAX was manufactured by a company called Digital, since swallowed up by
Compaq. DCL ran on top of the operating system, VMS (I suspect that stands
for virtual memory system
) so I was officially using DCL/VMS. I normally
just think of this as VMS (of which a modern free version is available
as OpenVMS) but most of the neat features
were really in DCL. It was actually a really good system, with some features I
sorely miss to this day – most especially the help command.
If you were sat in front of a console (that is, a screen and a keyboard
– there was no mouse yet) and you didn't know what to do, the obvious
thing to do was to type help
– and, if nothing happened, try
hitting the enter key to get it listened to. Try that on your nice shiny modern
computer – good luck with that. On DCL it actually gave you help
– real, straightforward, this is helpful
help. It didn't assume
you knew pretty much everything and just wanted to be reminded of some
details. It started from the basics and worked its way up – yet it did so
without encumbering the experienced user with wading through needless pages of
stuff they already knew. The command starts up the help application, which
was really well thought out. Remember I said you only get 25 lines and
80 characters on each ? It knew that, and it worked hard to (mostly) not
need more; I really think this was a great feature – it forces the help
author to deliver help in manageable chunks that the poor clueless user can
actually digest one at a time.
To make that possible, it was in fact making you navigate a hierarchy of
nodes, each of which comprised a chunk of expository text providing that node's
information plus a bunch of words you could type next to get to subordinate
nodes giving more information on parts of the topic, or on related topics; or
you could just hit return, without typing anything, to back out to the node's
parent. Not that it made you think like you were navigating a
hierarchy of nodes
: it just was doing that, and had a UI that made
it so natural you didn't need to think about it. When you first
typed help
it gave you about half a screen explaining how the help
application worked followed by half a screen of possible topics, identified by
keywords that the user was actually likely to recognise if they were what the
user wanted to know about. Each of those would give high-level details on its
topic and a list of sub-topics from which to learn more; and each of those did
likewise, until you drilled down to the actual information you were after.
This wonderfully simple approach (which, with hind-sight, must have had some pretty serious editorial work behind it) to help meant that it was actually possible to learn the system. I didn't need a training course, I just needed access to the computer.
The full name of a file looked (unless my memory tricks me) something like this: [root:sub.directory.name]filename.ext;123 and you usually didn't bother with the bit in square brackets, […] because you'd already typed cd root:sub.directory.name to set that as your working directory.
You also didn't usually bother with the ;123 version number; you
just typed filename.ext and the system used the highest-numbered
version of that available. If what you were doing changed
the file, the
program actually created a new file with a version number one
higher, filename.ext;124 in this example. This meant that you
retained old versions of your file, which was great for recovering from your
stupid mistakes. Every now and again, it was time to run a command (I suspect
its name was purge but it might have been clean or some
other approximate synonym) to throw away older versions (it probably had options
to specify how many versions of each file to keep, which files to apply to and
so on). Just make sure you've got working versions of everything before you do
that, because you're losing your back-ups.
This was way better than just having a single-backup system (many programs on modern systems will save filename.ext.bak or filename.ext~ or similar if you modify filename.ext, but that only lets you recover from your most recent mistake), although you did have to watch out to not fill the disk with redundant old copies.
In the file-name above, the directory started with root: and
there was some magic there, too. The name given here could be a drive name
(rather like the drive letters in DOS), in which
case root:sub.directory.name referred to a real physical directory
(or folder
, if you're more used to the desktop metaphor
)
called name
, that was a sub-directory of directory
which was,
itself, a sub-directory of sub
. All nice and simple.
However, you could also define a virtual mount-point
; you could
associate a name (I forget the exact syntax) with a sequence of directories
(which could, themselves, use virtual mount-points); if root was such
a name, then [root:sub] referred to the sub-directory sub
of each of the directories named
in root. Likewise, [root:sub.directory.name] referred to
the relevant sub-directories of those;
and [root:sub.directory.name]filename.ext referred to the
highest-numbered file of the given name in the first of these directories that
actually contained a file of that name. (Note that later directories in the
list would be ignored regardless of how high their version number might be.)
When you save a file, it gets saved in the first-named directory, even
if you created it by editing a file that didn't exist there previously.
Let's look at a simple example, to see how powerful that is. Say there's
some program a colleague has written, in a bunch of source files spread out in a
directory hierarchy under some directory of hers. I chose a working directory
in my file-space and make a root that refers to my working directory, then to
the top-level directory under which she's keeping her program and the scripts
that build it from its sources. Now I can edit
any of her files I like;
the editor saves the results in my file-space but all commands see all of her
files, except for the ones hidden by my edited local copies. So I can make my
changes and build my own version of her program – without having to copy
any of the files I haven't changed. Then I can tell her where my changes are
and ask her to integrate them back into her version. Before she does that, she
wants to check my changes are good, of course; but she can do the same as I did,
using a virtual mount-point to reference a scratch directory, then my working
directory, then hers; she can build her program that way to get my version and
try it out. If she's satisfied it's good, she can copy over my changed versions
into her own.
You can do that to any depth. Suppose you're working on a product built from lots and lots of source files spread throughout a big file hierarchy, but your team is only working on one chunk of that, and you're only working on part of your team's chunk. Let's suppose the definitive source tree has some form of quality control on it, that ensures changes aren't integrated until they've been tested and found to be good. So there's also a general development source tree that contains changes from all teams, that are waiting for integration. When your team completes a task, it copies its work up to that for the integrator to test and copy over to the definitive version. Your team also has an area in which you all collect together your parts of what you're working on; and each member of the team has their own working area. Notice that each of these source trees, aside from the definitive one, only contains such files as are changed, in it, relative to the definitive one. So you make a virtual mount-point out of all of those – first your own work area, then the team area, then the general development area, finally the definitive source tree – and get on with your work. If what you're working on depends on some colleague's on-going work, you can throw in his working directory. If some other team breaks everything by merging up their work to the general development staging area, you can take that out of your virtual mount point and carry on working while they sort out their mistake; put it back once they have.
The combination of DCL/VMS's automatic versioning and mount-points made it
easy to do things that require a distributed version control system on modern
computers. (There are also ways to do the virtual mount-point trick on modern
Linux file-systems, with copy-on-write semantics to ensure your changes are
always local to the front
directory of the stack.)
DCL/VMS only ever existed on Digital's computers, until OpenVMS came along, so it didn't spend the seventies and eighties having additional software written for it by others. It had plenty of applications written for it, to be sure, but it never had the commodity software industry that made DOS (and hence MS-Windows) such a success or the hacker community that enabled Unix to flourish behind corporate locked doors, ready to blossom once its free versions became available. Maybe OpenVMS will get that; but it has a lot of catching up to do.
By 1990, VMS had grown a graphical user interface that looked like everyone else's, more or less; but around the same time I was given a course in Unix (actually, as it happens, Xenix to begin with) and shortly afterwards got a job in which I moved to SunOS (now Solaris), a dialect of Unix. After a decade of mostly SunOS/Solaris (with stray doses of other Unix variants – AIX and HP-UX spring to mind) I was able to switch to Linux (which I'd been using at home for several years, by the time I switched at work), a free dialect of Unix. I never find time to play with OpenVMS but I still have fond memories of the system I used to use.
Written by Eddy.