munck@MITRE-BEDFORD.ARPA (07/05/84)
----------------
All,
In all of the discussions of the virtues and vices of UNIX, comparisons
with VMS and CMS, and arguments about its use with/as a programming support
environment, I think that we should acknowledge occasionally the fact that
it was inspired by and named for MULTICS. Many, if not most, of the highly-
touted features of UNIX were actually developed by the innovative and very
competent people who worked on the MULTICS project at MIT in the Sixties.
My MULTICS experience is at least a dozen years old, and blurred by the
many file systems and command languages I've collided with since; I can't
begin to describe its rich set of features off the top of my head. However,
given that the UNIX designers essentially "cut down MULTICS to fit"
smaller, more available machines, there may be many valuable concepts that
didn't make it into UNIX and that could be of use to us now. Anyone have a
dusty old MPM or MSPM lying around?
It has been suggested that UNIX owes much of its acceptance to the fact
that it was the first and for a long time the only OS that was fairly
machine-independent and for which the source code was available outside the
developing organization. It's interesting to speculate where we'd be now
if MULTICS had been done on a smaller, less exotic machine; all the C fans
would probably be using PL/I and just as vociferous as they are now.
/* Bob Munck, the MITRE Corporation */SIBLEY@USC-ECLB.ARPA (07/05/84)
Bob, Although I had a CTSS original in January, I "DELETED" IT VIA THE CIRCULAR FILE (while collecting my hernias) during an office move. However, I don't think we should look back (I can find a copy of Calvin Moore's Interactive typewriter proposal which precedes the pair, but would it help?). No, I fear the good ideas of the pre and post Project MAC are lost in infinity (Has anyone any idea of where Teager went?). Least is MULTICS, lest we feel it was a small thing? (or wasn't it a great pun but just misspelling). Regards, Edgar
WMM@ACC.ARPA (07/06/84)
From: Waiming Mok <WMM@ACC.ARPA> Re: Least We Forget: MULTICS Cc: INFO-UNIX@BRL-VGR Granted many features of UNIX derived from MULTICS, one thing most likely did not. That is its structural conciseness. This conciseness contributes to the large number of degrees of freedom in terms of UNIX's flexibility. If one would draw the analogy of PL/1 to MULTICS as C is to UNIX, I would choose C/UNIX anytime. Waiming Mok @ ACC ------
Eachus@HI-MULTICS.ARPA (07/07/84)
From: "Robert I. Eachus" <Eachus@HI-MULTICS.ARPA>
I've been waiting for someone to drop this shoe, but you seem to
have forgotten that Multics is not dead, but alive and well, and still a
much better development environment than Unix. In spite of all the
people who think that Ada was designed with Unix in mind, most of the
development work was done on Multics. I feel that many of the best
features of the program library concept in Ada would not be present
without the Multics background of the designers.
R. I. Eachusemjej@uokvax.UUCP (07/09/84)
#R:sri-arpa:-160800:uokvax:6100035:000:1145 uokvax!emjej Jul 8 16:51:00 1984 /***** uokvax:net.unix / sri-arpa!ARPA / 1:41 pm Jul 6, 1984 */ ...there may be many valuable concepts that didn't make it into UNIX and that could be of use to us now. Anyone have a dusty old MPM or MSPM lying around? /* ---------- */ No (and I wish I did have more info on Multics, too), but I would like to point out a facility of OS-9 that reminds me greatly of Multics segments, namely the OS-9 memory module. Said beast is a position-independent (by fiat), usually re-entrant hunk of program (or data) with surrounding descriptor and checksum. Perhaps it's a product of "salvation through suffering" (i.e. wishing to provide a multi- tasking Unix-like OS on 6809 boxes that didn't necessarily have memory management, so that they couldn't start out putting things at absolute addresses in initial versions and then move up to machines with virtual memory or memory management hardware so they could perpetuate the charade of absolute addresses), but in any case it allows the sort of dynamic linking I understand Multics is capable of. It's begging for a language on the order of Modula-2/CLU/Russell to run on it. James Jones
POBERNDORF@USC-ECLB.ARPA (07/09/84)
Bob,
We have at least one potential source for such information right on the
KITIA - Honeywell is one of the KITIA members. Let's bring this up again at
the Toronto meeting.
Triciammt@dciem.UUCP (Martin Taylor) (07/10/84)
"Least" seems appropriate, in view of the comment that had Multics
been done for smaller machines, people might now be raving about
PL/1 rather than C. I remember the first time I saw the Multics
system, people were having a party. They had just managed to get
the resident portion of the monitor (on a 256K machine) down to
300K. Not bad for a "least" system! How big was the first UNIX
written in C?
--
Martin Taylor
{allegra,linus,ihnp4,uw-beaver,floyd,ubc-vision}!utzoo!dciem!mmtbarmar@mit-eddie.UUCP (Barry Margolin) (07/10/84)
Hey, stop talking like Multics* is dead! There are some of us who still
believe in it. Me, I work for Honeywell doing Multics systems
programming. It was the first *real* computer I had ever used; I
learned computing on a PDP-8 in HS, and then hung around the Radio Shack
playing with Trash-80's for a while. When I came to MIT I learned what
a computer is supposed to do.
I might consider Multics dead when everyone's desktop Unix(tm) has
demand-paging, a tera-word per process segmented virtual memory
file-system, dynamic linking, and hardware support for three orthogonal
access control mechanisms. Yes, Unix has a number of important features
that Multics lacks. You might be interested to know that I don't
consider pipes to be one of them; pipes are a kludge to get around the
fact that dynamic linking was hard to implement, so instead of making it
easy to call lots of subroutines, you start up a process and read its
output.
--------------------
*Multics is a registered trademark of Honeywell Information Systems.
--
Barry Margolin
ARPA: barmar@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmartrb@masscomp.UUCP (07/10/84)
mit-eddie!barmar: > You might be interested to know that I don't consider pipes to be one > of them; pipes are a kludge to get around the fact that dynamic linking > was hard to implement, so instead of making it easy to call lots of > subroutines, you start up a process and read its output. Dynamic linking doesn't give you the toolkit versatility that the pipe system call (and its use in interactive shell pipes) gives you. My favorite simple example is the rhyming dictionary (I don't remember where I first saw this example). Given the v7 programs: sort: sort lines lexically rev: reverse order of characters in each line Then % rev < input-dictionary | sort | rev > rhyming-dictionary produces a (lexical) rhyming dictionary. Another simple example would be a spelling checker, using the v7 tools tr, uniq, and comm, along with a dictionary of correctly spelled words. I don't see how pipes are a kludge, they seem pretty elegant to me. The pipe system call and the shell pipe interface seems like an ideal way to provide a co-routine interface to naive users. How could dynamic links do this better (more simply)? (Oh no, I envision all the object oriented purists coming through the windows.) Andy Tannenbaum Masscomp Inc Westford MA (617) 692-6200 x274
dan@haddock.UUCP (07/11/84)
#R:sri-arpa:-160800:haddock:16700026:000:2967
haddock!dan Jul 9 20:09:00 1984
Multics was indeed responsible for many of UNIX's best features.
The innovation of UNIX was the notion of pipes, filters, and small
programs which could be quickly and easily coupled together to do
useful work. Also, UNIX was once much simpler than Multics, but I
don't think it's true any longer; compare either System V.2 or
Berkeley 4.2BSD to Multics, and I think you'll find it's a tie.
The things that Multics has (present tense--you can still buy one,
you know) that I miss on UNIX are consistency and dynamic linking. In more
detail:
* Consistency. Multics has a set of closely followed guidelines for
writing commands, which means that command names, arguments, and error
messages are very consistent. Command names and arguments have both long
descriptive names and short, easy-to-type names (e.g., create_dir and cd).
They are slightly more verbose than names and arguments in UNIX, but
they were much more consistent and much easier to remember as a result.
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".)
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?)
* 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). One of the first things I did when I started using Multics
was to replace the error-message routine with one of my own that gave briefer
messages. Someone else I know replaced the question-asking routine with one
that would take 'y' or 'n' in addition to the words 'yes' and 'no'. As
with UNIX, while it wasn't perfect, you could easily fix it--usually more
easily than with UNIX, in fact.
Another application of dynamic linking was the I/O stream facility, which
(among other things) permitted you to insert modules between all programs
and your terminal. If UNIX had this facility, there wouldn't be periodic
arguments about terminal paging--those who wanted it would just put it
in an I/O module to be inserted in your terminal output stream. (One creative
person wrote a "German" I/O module--it would give everything written to your
terminal a German accent.)
To quote Sherlock Holmes, "I have written a small monograph on the subject"
of dynamic linking, and I'll send it to anyone who's interested.dan@haddock.UUCP (07/13/84)
#R:sri-arpa:-160800:haddock:16700029:000:1451 haddock!dan Jul 11 17:35:00 1984 From barmar at mit-eddie: > ... pipes are a kludge to get around the fact that dynamic linking was hard > to implement, so instead of making it easy to call lots of subroutines, you > start up a process and read its output. In theory this might be true. In practice it isn't, because Multics programs aren't set up to be coupled together the way UNIX programs are, either through dynamic linking or any other way. I've had to cascade a series of operations using different Multics programs, and it just isn't as simple as 'prog1|prog2'. You can't dynamically link them together because they don't know how to call each other. You can redirect user_input and user_output (I/O streams), but you can't just couple user_output from one program into user_input of the next--because the next program typically can't be told to read user_input for its data; it only understands about named files. To do a UNIX 'prog1 | prog2', you have to say something like file_output temp (redirect user_output into file "temp") prog1 input (run prog1; its output is being collected in temp) file_output (redirect user_output back to the terminal) prog2 temp (so you can see prog2's output) And that only works if prog1 actually prints its output, rather than modifying the input file, which many programs do. I'll take the UNIX 'kludge' any day! Also, pipes implement coroutine-style linkage rather than call-return, which is often more useful.
cowan%hare.DEC@DECWRL.ARPA (07/13/84)
From: Ken Cowan ZKO2-3/L13 381-2198 <cowan%hare.DEC@DECWRL.ARPA>
I have to agree with Andy Tannenbaum that pipes are a marvelous
feature. If any of you have read Software Tools, remember that one of
the things they stressed was modularity of the design of your program.
Pipes provide another form of subroutine-type modularity, except you
are no longer sharing the global static storage (which is likely to
be the desired effect).
Once the user is comfortable with pipes, new ideas in the
area of functional languages become very natural. Functional languages
tend to extend pipe-like constructs to permit more structured data
flow than just sequential passing of data from one process to another
It is also likely that pipe-like ideas will be an integral part
of the multi-processor computer architectures being developed. I'm
sure there are better experts than I on this particular subject, since
I have not been following research in this area.
Ken Cowan
{ucbvax, decvax, allegra}!decwrl!dec-rhea!dec-hare!cowan
cowan%hare.DEC@decwrl.arpa
HARE::COWANguy@rlgvax.UUCP (Guy Harris) (07/19/84)
> 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
gwyn@BRL-VLD.ARPA (07/28/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> The idea of an improved, standardized error message function is a good one. Various implementations have appeared on USENIX tapes in the past. The problem is not so much in designing something more generally useful than perror(), but in getting universal acceptance of it. I wonder if AT&T will give serious consideration to suggestions like this now that they are supposedly more responsive to the marketplace. Unfortunately they seem to be getting sucked into targeting new work at the small system end user rather than at software developers.
henry@utzoo.UUCP (Henry Spencer) (07/30/84)
> The idea of an improved, standardized error message function is > a good one. Various implementations have appeared on USENIX > tapes in the past. The problem is not so much in designing > something more generally useful than perror(), but in getting > universal acceptance of it.... There is one possibility which might become a de facto standard if enough people use it: error() from Kernighan&Pike. We're using it here for everything new we do, and gradually retrofitting it (and a non-exiting version called "warning") into old programs. In general, one could do a lot worse than to open up Kernighan&Pike and start typing things in. K&P may be the closest look at Version 8 that we'll ever get... -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry