Least We Forget: MULTICS

[Guy Harris]

> Error messages on Multics were always of the form
>     progname: System error message.  Program-supplied error message.
> The error messages were complete English sentences, which was good for the
> novice, and programmers could easily replace them (see below).  (Messages
> like "The specified control option is not implemented by this command." did
> tend to get tiring after awhile on low-speed terminals, which is of course why
> UNIX programs just say "bad flag".)

Wasn't there a command that told the system to print short versions of the
error messages?

> UNIX has gotten better about this one; pr doesn't say "very funny" anymore,
> rmdir doesn't say "Values of B may be greater than dom!", and you're often
> told the name of the program that's failing, too!  Now if only you could
> learn the kernel error, too!  (USG, are you listening?)

Part of the reason for the poor error messages in UNIX programs is the
weak error-message printing routine.  Multics' "com_err" (or whatever it was
called, it's been a while), if I remember correctly, had a way to do
"printf"ing ("ioa_"ing, rather) within the call.  "perror" merely permits
you to stick a string in front of the system error message; if you want
something like:

	frobozz: /etc/passwd: No such file or directory

you either have to construct the "frobozz: /etc/passwd" string yourself
and feed it to "perror", or use the error message tables yourself - I've
gotten into the latter habit, because I've learned from bitter experience
how much of a difference clear and complete error messages can make (namely,
you don't spend 20 minutes sticking in debugging code to find out something
that a better error-message could have told you from the beginning).

> * Dynamic linking (which would fit very smoothly into the UNIX framework,
> and would have lots of advantages for program development), and extensive
> use of "library" routines for common tasks that anyone could replace (via
> dynamic linking).

In effect, it means that the ability to plug in a new kernel and run old
programs (a system call does sort of a dynamic link to a kernel routine) is
made available to code that isn't part of the kernel (Multics also permitted
the non-kernel code to be shared by all programs that used it) - in fact,
a "system call" in Multics was just a (semi-)ordinary subroutine call (through
a "gate" segment containing a transfer vector that meant that your process
ran in a more privileged "ring" while it was executing that subroutine and
the routines it called).  (Amusingly enough, the GE 635 had one "system call"
instruction, but the GE 645 that Multics originally ran on had *four* - *none*
of which were used for system calls under Multics!)

Unfortunately, dynamic linking does require you to create pointers that
1) have enough bits in them to efficiently refer to a character string that
contains the name of the routine being linked to while 2) causing a fault when
dereferenced; not all hardware supports this conveniently.  (It could probably
be done on a VAX, though, by mapping out the upper N bytes of the
system address space (N a power of 2) for some N big enough to hold all
the names of the routines and small enough not to be missed from the system
address space.  Or, by adding another level of indirection, it could be done
with a table of pointers to the strings, and N big enough to hold all those
pointers.  All the compilers would have to be changed to reference globals
not directly, but indirectly through one of those "trap pointers" - when
the trap occurs, the linker (in the OS) would map the segment containing
the global reference into your process' address space, and change the trap
pointer to point to the global.)

	Guy Harris
	{seismo,ihnp4,allegra{!rlgvax!guy

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy