Myths

Tom Van Vleck, John Gintell, Joachim Pense, Monte Davidoff, Andi Kleen, Doug Quebbeman, Jerry Saltzer

paragraphs by THVV unless indicated

Many statements about Multics on the Web and USENET are partly or completely incorrect. This note lists some of the most common myths and provides more accurate information.

1. Myth: Multics failed in 1969. Bell Labs quit, Multics survived.
2. Myth: Multics failed. Multics met its goals.
3. Myth: Unix was operational before Multics. False.
4. Myth: Multics was big and slow. True pre-release.
5. Myth: Multics was vastly expensive. You get what you pay for.
6. Myth: Ken Thompson wrote Multics. Ken was one of many.
7. Myth: Bell Labs folks wrote the first hierarchical file system. In original Multics design.
8. Myth: Multics was built by the waterfall method. Closer to spiral method.
9. Myth: Multics was closed source. We shipped with source.
10. Myth: MULTICS was designed with military security in mind. MLS was a separate project.
11. Myth: You had to give a password to log out. User app, terminal locker.
12. Myth: Multics error messages were in Latin. One was.
13. Myth: A 10 year old job. False.
14. Myth: Multics did not have file I/O, just mapped files. False.

There are some myths that arise as a result of believing early documentation:

1. Myth: Multics used multiple processes per user, and a two process debugger. Never true.
2. Myth: Every procedure executed in Multics consumed two segment numbers, one for code and one for linkage. Only pre-production.
3. Myth: The Multics file system provided a "trap" access control attribute. Never true.

There are some myths that give Multics too much credit rather than too little. We should correct these too.

1. Myth: Multics was the first interactive time-sharing system. CTSS, BBN, JOSS, SDC, DTSS, Berkeley.
2. Myth: Multics was the first system to use virtual memory. Atlas, Burroughs.
3. Myth: Multics was the first system written in a high level language. Burroughs B5000.
4. Myth: Ken Thompson's Unix was a rewrite of Multics. Not related.
5. Myth: Multics was "virus proof." Very virus resistant.
6. Myth: Multics never needed to shut down for maintenance. Part way there.

Myth: Multics failed in 1969

"...the increasing obviousness of the failure of Multics to deliver promptly any sort of usable system, let alone the panacea envisioned earlier." Dennis Ritchie , The evolution of the UNIX time-sharing system, Bell System Technical Journal 63, 8, Oct 1984.

"A group of four Bell Labs programmers continued on in their efforts, however, and worked to create a system that would succeed where Multics had failed. They named their operating system UNIX." Kevin Martin , Pair Networks Insider, "History of FreeBSD" , Sept 2001

"MULTICS failed, but it did inspire Ken Thompson, who was a researcher at Bell Labs, to have a go at writing a simpler operating system himself." Dr William J. Knottenbelt , Class notes, Intro to Unix , accessed Dec 2002

"1969 Unix is born at Bell Labs to replace the failed Multics operating system" anonymous , The History of Open Source Development , accessed Dec 2002

"Thompson and Ritchie were pulled out of the original MULTICS collaboration after the failure of 1966/7 era hardware to support its implementation" anonymous , Wikipedia, "Unix" , accessed Dec 2002

"The MULTICS project was abandoned. The GE 645 system was too slow and proposals for new equipment were rejected as too expensive." anonymous , "Linux Overview" , accessed Dec 2002

"Commercial development of the MULTICS project is abandoned after four years intense development. Multics involved MIT, GE and Bell Labs in an attempt to build a large scale time-sharing system for computer utilities." Prof. Thomas Haigh , ST297 Readings Timeline , accessed Dec 2002

Germ of Truth

From Bell Labs' point of view, Multics did fail to produce the time-sharing system they wanted when planned.

Facts

Bell Labs joined the Multics effort in 1965 through a "murky process" [Vic Vyssotsky] and chose to withdraw a few years later. Their goal in joining was to obtain an inexpensive time-sharing system for use by members of the technical staff at Bell Labs. They had various degrees of commitment to the Multics vision of a "computer utility" described in "Introduction and Overview of the Multics System."

When the planned time had passed, Multics was not ready to use as a time-sharing service, and it was clear that there was a lot more work to do. Bell was paying rent on its GE-645 and dedicating valuable people to the Multics effort, and continuing work on Multics would continue these costs with no trustworthy end date. They opted out in April 1969.

MIT and GE/Honeywell continued development of Multics. MIT began using Multics for "paying" academic and research customers in October 1969, and continued to run a Multics system for almost 20 years. Honeywell and its affiliates developed a new generation of hardware for Multics, announced it as a commercial product in 1973, marketed it until the mid 80s, and got several hundred million dollars worth of revenue from Multics.

Conclusion

The Multics project certainly didn't fail in 1969. We suffered a disappointing setback when Bell departed, but the project continued, the operating system continued to exist, to be used, and to grow and evolve, for many more years.

The 1973 replacement of the GE-645 by the Honeywell 6180 made a substantial improvement in Multics efficiency and performance. The 6180 and its descendants supported ICs instead of discrete transistors, new CPU architecture including many new instructions and registers, and a new I/O controller.

Myth: Multics failed

"The roots of UNIX date back to the late 1960s. Ken Thompson joined Bell Labs in 1966 in the Computing Research Department, which is when he started working on the Multics project, a very ambitious effort to create a next-generation portable operating system that eventually failed. " Ken Milberg , Article in IBM DeveloperWorks, accessed 03 Dec 2009, now missing

"Bell Labs pulled out of the project when Multics displayed signs of bloating into an unusable white elephant (the system was later marketed commercially by Honeywell but never became a success). " Eric Raymond , Open Sources , date?, also in Jargon file

"Multics, a terrific and influential failure. Once upon a time in the mid-Sixties, three companies, MIT, Bell Labs and General Electric, decided to create a "computer utility" sort of like a power company, which would provide computing resources to an entire city or area. Their project, called MULTICS for Multiplexed Information and Computing System, was a failure due to the enormity of the project and the vast budget overruns." anonymous , canisius.edu, "A Short History of Unix", accessed Jan 2003

"In what became one of the most famous instances of feature creep in the history of computer science, Multics failed to accomplish any of its original objectives set out by AT&T because the developers of the system were trying to incorporate every innovation they could think of into a system that didn't actually require it." John Loeffler , interestingengineering.com, "UNIX: Building The Most Important OS in the World," , accessed Mar 2019

Germ of Truth

Multics didn't sell to as many customers as its builders and advocates had hoped. Honeywell Bull stopped development of Multics in 1987 and stopped hardware production. No Multics sites are now running. The last one shut down in October 2000. (An open source Multics simulator is available.)

Corby's 1991 Turing Award lecture was titled "On Building Systems That Will Fail", and discussed Multics. So one might conclude that he thought of Multics as a system that failed.

Facts

[JWG] Bull canceled Multics development after 21 years. Multics continued to be used by customers for an additional 14 years. (See the Site Timeline.) In several cases, the lengthy period of Multics use after cancellation was needed to find and develop the capabilities provided by Multics on other systems.

Dick Hill's story of Honeywell corporate politics shows how the cancellation of Multics had nothing to do with its technical abilities or its sales: it simply had no champion in the executive suite.

In Corby's Turing talk, he said, "That Multics succeeded is remarkable for it was the result of a cooperative effort of three highly independent organizations and had no administrative head." I could stop right there. Corby, our leader, said we succeeded. He also said,

"we were misled by our earlier successes with previous systems such as CTSS, where we were able to build them "brick-by-brick," incrementally adding ideas to a large base of already working software.

We also were embarrassed by our inability to set and meet accurate schedules for completion of the different phases of the project. In hindsight we should not have been, for we had never done anything like it before. However in many cases, our estimations should have been called guesses.

The UNIX system [12] was a reaction to Multics. Even the name was a joke. Ken Thompson was part of the Bell Laboratories' Multics effort, and, frustrated with the attempts to bring a large system development under control, decided to start over. His strategy was clear. Start small and build up the ideas one by one as he saw how to implement them well. As we all know, UNIX has evolved and become immensely successful as the system of choice for workstations. Still there are aspects of Multics that have never been replicated in UNIX.

As a commercial product of Honeywell and Bull, Multics developed a loyal following. At the peak there were about 77 sites worldwide and even today many of the sites tenaciously continue for want of an alternative."

Concerning "bloating:" our pre-implementation design of Multics was too complex, and we spent great effort in the first few years of development on simplification and major optimizations (e.g. single sized items in most system structures, binding, single process per user, mini-shell, etc.) and in the early 70s with hardware support for rings and string processing. These transformations were largely accomplished by the mid 70s. See below.

As described in the 1965 paper "Introduction and Overview of the Multics System" by Corbató and Vyssotsky, the operating system designers had nine major goals for Multics:

Goal	Accomplishment
Convenient remote terminal use.	Met. Set the standard.
Continuous operation analogous to power & telephone services.	Partially met. Never as reliable as power and phone.
A wide range of system configurations, changeable without system or user program reorganization.	Partially Met. A single system boot tape worked on any Multics configuration. User programs were insulated from the configuration. It was possible to add and remove CPUs, memory, and I/O controllers without restarting the system.
A high reliability internal file system.	Met. First modern file system. Hardware and software reliability improved over time.
Support for selective information sharing.	Met. Set the standard.
Hierarchical structures of information for system administration and decentralization of user activities.	Met.
Support for a wide range of applications.	Met.
Support for multiple programming environments & human interfaces.	Met.
The ability to evolve the system with changes in technology and in user aspirations.	Partially Met. Continued to evolve for over 20 years.

Berkeley Tague, who worked on Multics at Bell Labs, wrote "Multics was one of the seminal efforts in computing science and operating system design. It established principles and features of operating system design that are taken for granted today in any modern operating system."

(Further concerning "bloating," it is fair to remark that some of the more baroque features of the MSPM design and early implementation, say 1966-67, were proposed by Bell Labs members of the team. The multi-process shell design, the concept of an I/O system general enough to support an online peripheral oil well, and some of the initial concepts for core allocation come to mind.)

Conclusion

[JWG] Multics met the goals it originally set out to meet. In addition, it had modest commercial success, and many of the customers used it for a wide range of to-them mission-critical applications for which there were no suitable alternatives available.

Multics had a degree of (marketing) success in the late 1970s and early to mid 1980s. Those successes were followed by (marketing) failures, for many reasons. It's a long story.

There's no way to get around it: we failed to attain permanent success. People are now using other systems.

Myth: Unix was operational before Multics

"an early version of UNIX was operational several months before MULTICS" Garfinkel and Spafford , Practical UNIX & Internet Security date?

Germ of Truth

Unix first execution in 1969 may have preceded the first use of Multics at MIT for "paying" users in October 1969.

Facts

This is comparing apples and oranges. The Multics Phase One milestone was the first time Multics actually worked. This came in late 1967, years before Unix was started; Ken Thompson and Dennis Ritchie were part of the BTL team working on Multics then, using CTSS remotely from New Jersey.

Quote from Dennis, in "The Unix Time-Sharing System: A Retrospective," Bell System Technical Journal July-August 1978, Vol 57 No 6 Pt 2, pp 1947-1969:

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. Today, more than fifteen years after CTSS was born, few of the interactive systems we know of are superior to it in ease of use; many are inferior in basic design."

Multics was self-hosting since late 1968; that is, system programmers used Multics to build Multics.

Conclusion

False.

Myth: Multics was big and slow

"... development of an operating system called Multics which aimed to improve the performance of multi-user time-sharing computer systems. But the resultant system was too big and too slow, so Bell labs withdrew leaving the computing science group without a computer." Mr. Liam Madden , www.ee.ic.ac.uk, Unix for the first time , accessed Dec 2002, now missing

"In the 1960?s, several monopolies teamed up to create the greatest operating system that never was. General Electric, MIT, and Bell Labs collaborated on the 'Multics Project' -- a fast, efficient operating system. The trouble was, Multics was too big. It didn't fit well on any existing hardware. (Just like IBM's OS/360 -- bloat, bloat, bloat.) Multics solved many engineering problems in software, but did too many things. " Bill Leahy , Intro to Object Oriented Programming , accessed Dec 2002, now missing

"Bell Labs wasn't quick to oblige them, however. Multics was one of the biggest hogs for system resources and had grown out of control during its development there. The administration didn't want to see another Multics happen so long as they were alive." Nick Moffitt , Nick Moffitt's $7 History of Unix , accessed Dec 2002

Germ of Truth

Multics was slow in its infancy, like many systems. The story "How Many Users?" describes how slow it was before initial release. This is the performance that Bell Labs observed in the late 1960s.

In the 1960s, Multics was big compared with other operating systems; it supported bigger, faster hardware configurations, and promised support for more users, more storage, more languages, more memory for application programs.

In the 1990s, Multics was still running at several sites on obsolete and comparatively slow hardware, because Honeywell did not produce new Multics hardware that was competitive in speed.

Facts

There's a time skew here: often people talk about the problems of the 60s and apply then to the Multics of the 70s and 80s, a much more mature system on different hardware.

Multics (then) was small compared to e.g. Linux and Windows (now). The Multics "kernel" was about 250K source lines of code (SLOC) in 1978. The Linux kernel was > 4.5M SLOC in 2002, 27.8M SLOC in 2020.

Multics was slow compared to less capable systems: for example, DTSS could run many more users, each typically using a 16K (words) memory partition. A Multics process was much bigger and more flexible. On relatively slow hardware, with many users, Multics was slow. And the ability to easily build much bigger Multics programs than other systems supported led users to want more speed and responsiveness.

Multics was big compared to (most) of its peers in the 70s, and there were those, like Herb Grosch, who thought it too big to ever build. But it did get built, and met its objectives. Now, Multics seems remarkably lean compared to systems such as Windows.

In the 1970s and 80s, Multics won many competitive benchmarks, showing that it out-performed other systems that could do what Multics did. For example, we won USGS, EOP, DND, Bell Canada, and multiple university site benchmarks.

The Unix kernel started tiny and grew as features were added and additional hardware was supported. The June 2021 paper "Evolution of the Unix System Architecture" by D. Spinellis and P. Avgeriou shows the growth of Unix and BSD kernels. Descendants of Unix such as BSD and Linux have grown to be far larger than Multics and have many more features than Multics.

[MND] Part of this myth may also stem from Multics being written in a high-level language. Today, this is commonplace, but in the mid-60s to 70s, an OS written in a HLL would, a priori, be judged to be big and slow. Especially since Multics was written in PL/I, which had the reputation of itself being big and slow. Of course, the quality of code produced by the Multics PL/I compiler improved significantly over time.

(Monopolies. What's up with that? What was MIT a monopoly of? GE had a lot of divisions but I don't think it was a monopoly of anything. Maybe Bill is thinking of Western Electric.)

Conclusion

Once true, before release.

Myth: Multics was vastly expensive

"$6M/yr for 5 years" Prof. Eric Brewer, Berkeley , Berkeley CS262 Lecture Notes , accessed Dec 2002

Germ of Truth

Perhaps this figure was estimated from $2M/yr for all of Project MAC from ARPA and "comparable" from BTL and GE, but MAC included a lot of other research activities, and BTL/GE budgets would be hard to pin down.

Facts

I think this is way too high; I wrote Eric to ask where he got the number; he can't remember.

(I should get the Kenneth Flamm book, Creating the Computer: Government, Industry, and High Technology, (Washington: Brookings Institution), 1988, and see what it says.)

Writing operating systems is expensive. The Multics effort had fewer people than teams for other comparable systems. The Multics team had maybe 150 developers at its largest, counting all organizations. IBM had thousands of programmers working on OS/360. There were over a thousand working on IBM TSS, according to Lynn Wheeler.

Conclusion

Not "vastly."

Myth: Ken Thompson wrote Multics

"If I remember my UNIX history correctly, Ken Thompson wrote MULTICS, which was supposed to be a multi-user OS. However, it failed quite miserably at the multi-user level." Mike Digdon, Dalhouse University, Halifax NS , unix-wizards mailing list, 1992

"Ken Thompson, co-author of Multics" anonymous , IC Selection Guide article on Unix , accessed Dec 2002, now missing

Germ of Truth

Ken worked on Multics.

Facts

Ken was a respected equal, one of about 25 members of the Bell Labs Technical Staff who worked on Multics in 1965-1969.

Conclusion

Ken was a great programmer. He didn't write all of Multics. He contributed a piece to it, like a lot of others.

Myth: Bell Labs folks wrote the first hierarchical file system

"Thompson, Ritchie, and Rudd Canaday, another Bell Labs researcher, soon took the historic first step of putting down on paper the outlines of an entirely new type of file system for a computer. They envisioned how files could be categorized and placed in containers which could themselves be placed in other containers, creating a navigable file directory -- the same system used by every modern computer in the world today." John Loeffler , interestingengineering.com, "UNIX: Building The Most Important OS in the World," , accessed Mar 2019

Germ of Truth

The Unix file system does allow directories to contain other directories.

Facts

The 1965 paper "A General Purpose File System for Secondary Storage," by R. C. Daley (MIT) and P. G. Neumann (BTL), describes a file system that allows directories to contain other directories. The 6 FJCC papers were distributed to everybody working on Multics.

In his May 1999 IEEE Computer interview, Ken said, "The one thing I stole was the hierarchical file system because it was a really good idea."

Conclusion

I don't know where Loeffler got this idea.

Myth: Multics was built by the waterfall method

"Multics, in contrast, was a painstakingly planned and coordinated system of enormous ambition." Prof. Thomas Haigh , Review of Multics and Multicians web site in Iterations , Oct 2002 (no longer online as of 2021)

Germ of Truth

1. We wrote 3000 pages of the Multics System Programmer's Manual first, while waiting for the PL/I compiler promised by BTL. Some of this was science fiction. (One early I/O System design section mentioned the "on-line peripheral oil well.") Other parts of it provided high level functional specs for facilities we never built. Other parts had low-level PL/I declarations of code that might or might not compile.

2. People working on Multics were paid to do so, and had managers who directed their efforts. We thought before we coded.

Facts

Painstakingly planned and coordinated? That's not how it felt at the time. We wrote planning documents, not to too great a level of detail, but the implementation often departed from the original plan. Most projects were carried out by small teams, one or two people, who designed and implemented an improvement to the current version of Multics. Our process was more like the "spiral" process, iteratively discovering requirements and implementing partial solutions. See "The Multics Software Development Process" for a description of our process.

In effect, our practice tried to treat all software development, new features and bug fixes alike, as incremental maintenance, somewhat like the current development practices for Linux, but with fewer players: e.g. the distribution team was part of the same organization as the development team.

IBM had thousands of people working on OS/360. The Multics software development team, counting everybody, was barely over a hundred at peak. Of these, a small group led development.

Conclusion

Understandable wrong impression, since it wasn't written up anywhere.

Myth: Multics was closed source

"Multics died mostly from being proprietary and running on proprietary hardware." anonymous poster , Slashdot posting

Germ of Truth

Multics source is not GNU licensed. The hardware was proprietary.

Facts

Our original plan was for Multics to be open and portable. In "Introduction and Overview of the Multics System" (1965), Corbató and Vyssotsky write:

It is expected that the Multics system will be published when it is operating substantially and will therefore be available for implementation on any equipment with suitable characteristics. Such publication is desirable for two reasons: First, the system should withstand public scrutiny and criticism volunteered by interested readers; second, in an age of increasing complexity, it is an obligation to present and future system designers to make the inner operating system as lucid as possible so as to reveal the basic system issues.

Bull HN has made the entire source available "for any purpose and without fee" at MIT as of November 2007.

[MND] It may be helpful to point out that Multics predates the GNU project. Using contemporary definitions of open source to judge software from the mid-60s to 70s is comparing apples to oranges.

[Joachim Pense, Mainz] The source was delivered together with Multics. There even existed a "library_fetch (lf)" command that provided easy access to the source of any multics program. As most of the source was written in well-structured and well-commented PL/1, it was a real source of knowledge. Info segment for library_fetch command.

An open source simulator for the Multics machine created by Harry Reed and Charles Anthony is available for public download as of November 2014. Anyone can download and install the simulator and system software, and run a version of Multics on Windows, MacOS, or Linux.

Conclusion

It's open now.

Myth: MULTICS was also designed with military security in mind

"MULTICS was also designed with military security in mind, both to be resistant to external attacks and to protect the users on the system from each other. By design, Top Secret, Secret, Confidential and Unclassified information could all coexist on the same computer: the Multics system was designed to prevent information that had been classified at one level from finding its way into the hands of someone who had not been cleared to see that information. Multics eventually provided a level of security and service that is still unequaled by many of today's computer systems -- including, perhaps, Unix." Garfinkel and Spafford , Practical UNIX and Internet Security , 2003, page 12.

Germ of Truth

Security was important from the beginning, and Project MAC was funded by ARPA. Classification features were added later.

Facts

Multics inherited the notion from its CTSS roots that hardware-enforced security is much more reliable than security provided by software alone.

There was never any discussion of military-style classification when the fundamental Multics security mechanism was being designed. (The Ware Report, which discussed security controls for computer data, was not written until 1967. Multicians contributed to it.) Descriptor-based security supported by ACLs could be used to implement many security policies including the military system. Multics rings of protection are hierarchical, but work differently from the military classification hierarchy.

Military security support (TOP SECRET and so on) was added to Multics in the mid-70s, by Project Guardian's introduction of the Access Isolation Mechanism. Because Multics security centralized the security enforcement, adding additional rules to the access mechanism was an extension to the existing design. The article B2 Security Evaluation describes the evolution of Multics security.

[JHS] If one interprets "military security" to mean "multilevel security", then the myth is false. If one interprets "military security" to mean military-strength security, then the picture changes a bit: Ted Glaser (who was a consultant to the National Security Agency) wanted Multics to have security that was good enough that it could be used in military and even NSA applications. He advocated ACLs as being a close match to the military security principle of need-to-know. Ted's security design principle, again arising from a military security perspective, was that you can't add security later, it has to be designed in from the beginning.

Conclusion

Ted Glaser's military-inspired approach to security motivated the Multics team to use a rigorous approach to security design. Multics did not add military-style classification features till the mid 70s.

Myth: You had to give a password to log out

"among other things, on some versions one was commonly required to enter a password to log out." Eric Raymond , Jargon file , accessed Dec 2002

Germ of Truth

There was an author-maintained command at MIT called lock_console (lkc) which required a password.

Facts

If somebody ran lock_console, then you had to give the password so you could issue a command. (This kept people from "putting you on the cookie monster" if you stepped away from your terminal.) You could hang up the phone to disconnect the current session, and then reconnect and log in.

The same situation is true now, if you set a screen saver password on your Windows, Mac, or Unix box: you have to give a password in order to log out.

Conclusion

not true.

Myth: Multics error messages were in Latin

"GE's Multics system used Latin for all error messages; the intent was that this would prevent the end users from trying to outsmart the system, and would encourage them to call the adequately trained support staff to determine the nature of the problem." Peter Seebach , Article in IBM DeveloperWorks , Feb 2002

Germ of Truth

It happened once: see Hodie Natus Est Radici Frater.

Facts

As described in Bernie's story, one "can't happen" message did happen, when the hardware was broken, and his Latin message appeared, and I got called at home at 6AM on a Saturday morning.

The rest of the story is completely fabricated. Multics provided English error messages, with considerable care taken to make the wording understandable. The stuff about the "intent" is completely wrong. There was no such intent. There was no such practice. (Further evidence that the writer had no idea what he was talking about is seen in the phrase "GE's Multics." Honeywell had taken over the GE computer division for over seven years when the event in question happened.)

Seebach writes, "I wasn't trying to be funny, but I was apparently mistaken; I can't recall where I got this originally; it would have been from one of two or three sources, and I'll go poke around and find out where I got it."

Conclusion

not true.

Myth: A 10 year old job

"In Multics, shut down machine, found 10-year-old job" (On a slide about schedulers, and how some jobs might be starved forever.) Prof. John Kubiatowicz, Berkeley , Lecture notes for Berkeley course CS162 , accessed Oct 2015

Germ of Truth

On an overloaded system, processes that run a long time between interactions would sink to the bottom of the scheduler queues and make no progress.

Facts

This sounds like an urban legend. There's no evidence that it ever happened, no site is specified, and the terminology used doesn't sound like Multics.

Besides, when a Multics system is shut down, the scheduler queues are discarded. There would be no way to find a process that was starved out of completion. And no Multics system I ever heard of had an uptime of 10 years.

The only "job" concept in Multics was the facility to submit an "absentee job" with a list of commands. That wouldn't be relevant to a scheduler starvation discussion.

Conclusion

False.

Myth: Multics did not have file I/O, just mapped files.

"First off, Multics didn't have files as such. Instead it had named segments that were mapped directly into memory ('initiated' in Multics terminology). Thus accessing a file required you to manipulate the file contents as one large memory buffer. The classic Multics way of doing this was to describe the file as one PL/1 structure (very similar to a C struct)." Ian Mason , Comment on blog Schneier On Security , September 19, 2007

Germ of Truth

Files in the Multics file system could be mapped into addressable segments in a process's virtual memory. Many system commands accessed data in this way.

Facts

Multics has both memory-mapped I/O and traditional stream file system calls. Memory-mapped I/O is efficient for direct access to data that is a megabyte or less. Calling hcs_$initiate maps a file-system file into a directly addressable segment. File system calls provided by iox_ can pipeline processing provided by configurable modules and provide many more features, and operate on data larger than a megabyte.

Multics processes have standard I/O control blocks (IOCBs) set up at process creation: they are named user_input, user_output, and error_output. These names are similar to Unix conventions, where processes are created with file descriptors for STDIN, STDOUT, and STDERR. The Multics I/O system interface iox_ defines 17 operations on IOCBs: attach, detach, read, write, and 13 more.

The I/O system attaches an IOCB through an outer module to a destination. Outer modules are I/O programs that implement the Multics I/O interface and can be called via iox_ entrypoints. (Outer modules that interface directly to hardware devices are called Device Interface Modules, or DIMs.) Outer modules can be chained: for example, a module can pass operations through to another module, and also copy a trace of operations to a log file. (In the 60s, someone wrote an outer module that translated information from and to Pig Latin.)

The "destination" for an outer module depends on its function: it can be another IOCB, or a system device identifier, or something else. The vfile_ outer module connects an IOCB to a file system file. In addition to character stream access to memory segments, vfile_ supports access to and from multi-segment files, including supported keyed sequential record I/O to and from both single-segment and multi-segment files. (Internally, vfile_ uses segment mapping operations.)

If you inherited a PL/I, COBOL, or FORTRAN program that ran on some other system and used the traditional I/O statements, you could probably compile the program on Multics and run it without modification, by attaching the language's I/O units to Multics I/O streams using the io_call command.

Conclusion

Incorrect. Multics had memory-mapped files and stream-accessed files.

Myth: Multics used multiple processes per user, and a two process debugger.

Technical Report IR-LP-31-21, September 1989, The Design and Implementation of a Two Process Prolog Debugger, Diomidis Spinellis

Germ of Truth

Elliott Organick's 1972 book, The Multics System: An Examination of Its Structure, gives this impression.

Facts

This scheme was designed and described in the MSPM, but never used. Processes in Multics were heavyweight, and their creation was quite expensive. As a result, a much simpler scheme was devised that created one process per logged-in user, and ran procedures within it. The debugger was customarily invoked and the procedure to be debugged run "under" it, in the sense that the debugger's stack frame was an ancestor of the procedure under test.

Conclusion

Not true.

Myth: Every procedure executed in Multics consumed two segment numbers, one for code and one for linkage.

Germ of Truth

Elliott Organick's 1972 book, The Multics System: An Examination of Its Structure, gives this impression.

Facts

This scheme was used briefly but abandoned before Multics was put into service, in favor of copying linkage section templates for each procedure executed into a per-ring Combined Linkage Segment. This method handles multi-ring execution and unlinking cleanly and conserves segment numbers.

The "KST story" mentioned by Dennis Ritchie is a similar bug in pre-production versions of Multics, fixed early.

Conclusion

Only during pre-production.

Myth: The Multics file system provided a "trap" access control attribute.

Making PEACE a Dynamic Alterable System (1990) Henning Schmidt EDMCC

Germ of Truth

The initial paper on the Multics file system, A general-purpose file system for secondary storage, says that we planned to do this.

Facts

The paper describing the trap attribute was written before we implemented the file system. When we came to actually code this feature, we discovered a fundamental problem: it was difficult, in the one-process-per-user Multics model, to run the trap procedure in a correct security context. Running it in the referencer's context would create a Trojan Horse -- referencing a file could cause arbitrary code to be executed. Creating a separate context would be extremely costly. We deferred the implementation while we thought this problem over, and eventually abandoned the trap attribute idea altogether.

Conclusion

not true.

Myth: Multics was the first interactive time-sharing system

"A group at the Massachusetts Institute of Technology made the first attempt at developing an Operating System that could provide multiple users with interactive processing. The name of the Operating System was Multics. For the first time different types of Programs could be run simultaneously, and immediate response to typed-in commands was possible." tresmont@wxs.nl , Stichting Digidome, UNIX systems , accessed Dec 2002

Germ of Truth

?

Facts

The JOSS, CTSS, BBN, SDC, DTSS, and Berkeley time-sharing systems all preceded Multics. MIT's Whirlwind, even earlier, was an interactive system, for one user.

Conclusion

False.

Myth: Multics was the first system to use virtual memory

"The Michigan Terminal System (MTS), along with Multics at MIT, were the first operational virtual memory operating systems in the world." David L. Mills , The Michigan Terminal Systems , accessed Dec 2002

Germ of Truth

MTS was made available to the UM campus in May 1967. (Josh Simon)

Facts

The Atlas system had a paged virtual memory before Multics or MTS.

The Burroughs B5000 had segmented virtual memory before Multics or MTS.

The Rice Institute Computer was the first machine with a segmented memory architecture, before Multics or MTS.

CTSS used swapping to provide virtual machines to multiple time-sharing users in 1963.

Conclusion

False.

Myth: Multics was the first system written in a high level language

"Multics was the first major OS written in a High Level Language. Multics and Algol represented the best the world had to offer in software technology in the early 70's." Chuck Flink , Flink Ink, 2000-01-13 Embedded Linux Strategies , accessed Dec 2002

Germ of Truth

?

Facts

The Burroughs system for the B5000 was written in Algol and preceded Multics.

Flink, above, gives the impression that Multics was written in Algol. This is wrong also. Multics was written in PL/I.

CTSS had two modules written in MAD and one in AED-0.

Conclusion

False.

Myth: Ken Thompson's Unix was a rewrite of Multics

"Thompson soon realized that he could do the same for the Multics system as a whole, and over the course of a single month in the summer of 1969 he rewrote a large portion of the Multics to run on the PDP-7." John Loeffler , interestingengineering.com, "UNIX: Building The Most Important OS in the World," , accessed Mar 2019

Germ of Truth

?

Facts

Ken wrote the smallest time-sharing kernel he could, in PDP-7 assembly language, and then incrementally improved it. It was not derived from Multics, or from any of the other time-sharing systems available in 1969.

Conclusion

False.

Myth: Multics was virus proof

"Back in the 1970's and early 1980's we knew how to build operating systems that were rock solid and virus-proof. How long will we have to wait for someone to re-invent MULTICS with a GUI on top of it?" Marcus Ranum , Computer Security: An Utter Failure , May 11, 2006.

Germ of Truth

Multics was more secure in the 70s than most systems are today.

Facts

If you tricked a Multics user into running a program you supplied, you could take over his account and do anything he could do. The Cookie Monster Story makes this clear. Such a compromise would affect only one account on a Multics machine, not the whole computer, unless the account belonged to a highly privileged user. System maintainers and administrators were serious about maintaining the security of the installation. In contrast, modern PCs are often administered by users who have little concern for system security, and who install untrusted code.

The Multics mail programs did not provide "convenience" features for automatic execution of programs mailed to the user, or interpretation of structured content such as graphics. The Multics architecture is more resistant than current popular systems to misbehavior such as buffer overflows: PL/I string operations respect the length of the target string, the stack grows toward higher addresses instead of lower, the stack and data segments are non-executable, the hardware checks supervisor arguments, etc. But implementation mistakes in the security mechanisms could still happen.

One reason for the Multics mandatory access control feature was to prevent a rogue program from leaking sensitive data. Even with the use of the Access Isolation Method, timing channels were still a concern.

Conclusion

Virus resistant, but not virus proof.

Myth: Multics never needed to shut down for maintenance

"During a previous boom, General Electric designed a mainframe that it claimed would be sufficient for all the computer uses in Boston, and would never need to be shut down for repair or for software tweaks. The machine it eventually built wasn't nearly big enough, but it did succeed at running continuously without need for hardware or software changes."

"The real continuous approach comes from Multics, the machine that was never supposed to shut down and that used controlled, transparent change.... if an interface took more than one parameter, all the parameters were versioned by placing them in a structure with a version number. The caller set the version, and the recipient checked it." Paul Stachour and David Collier-Brown , You Don't Know Jack About Software Maintenance , ACM Queue, Nov 2009

Germ of Truth

Dynamic reconfiguration let us do some hardware maintenance without shutting down. Non-hardcore modules could be updated while Multics was running. Versioned interfaces were used in several interfaces.

Facts

Paul and David intended "a rather lighthearted look at various subject that people think they understand, but don't." Their article makes its point with wit and hyperbole, but it describes Multics features as if they were universal, when in fact they were applied in limited cases.

Multics dynamic reconfiguration allowed system operators to add and drop CPUs and memory, and later I/O controllers, while Multics was running. Peripherals and disk drives could be added and removed dynamically. I don't think it was possible to do major I/O reconfiguration, such as adding a disk controller, without shutdown. Many serious maintenance operations did require Multics to shut down and restart.

Replacing any module of the hardcore Multics supervisor required killing all processes and restarting the OS. In part this was because the kernel "leaked" facts into the user process, such as TTY descriptors and I/O channel bindings. (I wrote some design memos in 1980 or so about how we could make Multics reboot without discarding old processes, but it never made it into a Multics release.)

Some non-hardcore, non-daemon programs could be replaced while Multics was running. We did this by renaming old modules and leaving them on disk, and installing new versions. New processes would get the new versions, while processes that had already linked to the old versions would continue to use those. (A Multics process usually lasted for a whole login session, unlike Unix, which creates a process for each command execution.) The "versioned interface" practice was used in a few Multics facilities, but was not widespread.

David writes: "In fact, Multics started us on the path to solving the problem, and took us surprisingly far. The continuous change algorithm in the article is indeed a Multics approach, circa 1984. There is a brief mention of it in the "Level 68 Standards, System Designers' Notebook" (1980), p 2-6, a book I use to this day to guide my Java programming (;-)) "

Conclusion

We got part way there.

Similar pages

Readers may also enjoy Michigan Terminal System Myths and misconceptions.