Difference between revisions of "Multics"
('minicomputers'?? I don't think so!) |
(Add some more high-level desc) |
||
| Line 1: | Line 1: | ||
| − | Multics (''Multi''plexed ''I''nformation and ''C''omputing ''S''ervice) was an early time-sharing operating system for | + | Multics (''Multi''plexed ''I''nformation and ''C''omputing ''S''ervice) was an early [[time-sharing]] [[operating system]] for which has influenced every operating system created since; especially via [[Unix]] (the name of which is a play on 'Multics'), which was created by Bell Labs personnel who had worked on Multics, after Bell Labs pulled out of the Multics project. |
| + | |||
| + | Multics was intended as an ''information utility''; i.e. a service to which those who wanted information processing would connect, much as people connect to the electric grid for power. | ||
| + | |||
| + | This dictated a number of Multics' features, including the modular structure of the hardware (with multiple [[CPU]]s and [[main memory]] banks, fully interonnected, and with the ability to take individual units out of service for maintenance, or to simply add additional units as demand increased over time); extremely robust security (so that individual users in a facility open to all comers would be protected from each other), etc. | ||
| + | |||
| + | ==Technical aspects== | ||
| + | |||
| + | In addition to the modular hardware, and robust security, Multics had a number of other major technical features, some commonplace now, but major advances when it was first devices (in 1967). They include: | ||
| + | |||
| + | * A [[single-level store]] | ||
| + | * [[Dynamic linking]] for libraries, etc | ||
| + | * A [[command processor]] implemented entirely in user code | ||
| + | * A hierachical [[file system]] | ||
| + | * Separate [[access control list]]s for each 'file' | ||
| + | |||
| + | The single-level store architecture of Multics was particularly significant: it discarded the clear distinction between [[file]]s (called ''segments'' in Multics) and [[process]] memory. The memory of a process consisted solely of segments that were mapped into its [[address space]]. To read or write to them, the process simply used normal [[instruction]]s; the operating system took care of making sure that all the modifications were saved to [[secondary storage]] ([[disk]]). | ||
| + | |||
| + | In modern UNIX terminology, it was as if every file were 'mmap()'ed; however, in Multics there was no concept of process memory, separate from the memory used to hold mapped-in files: all memory in the system was part of some segment, which appeared in the file system; this included the temporary scratch memory of the process, such as its [[kernel]] [[stack]], etc. | ||
== Multics today == | == Multics today == | ||
| Line 9: | Line 27: | ||
=== Reviving Multics? === | === Reviving Multics? === | ||
| − | Porting Multics to alternative hardware would be a worse-than-Herculean task | + | Porting Multics to alternative hardware would be a worse-than-Herculean task: the design is not well-suited for porting. It used specialized hardware built especially for it, which had many features which do not have exact analogues on any other platform today. In addition, the word length of the machine (18-bit half-words) is explicitly included in many variable declarations in every source module. |
| − | Even if that could be overcome, Multics was written in PL/I. There are no PL/I compilers available other than commercial ones aimed at large enterprise systems, and which aren't getting any cheaper. | + | Even if that could be overcome, Multics was written in PL/I. There are no PL/I compilers available other than commercial ones aimed at large enterprise systems, and which aren't getting any cheaper. The lack of a free Unixland PL/I compiler inhibits any porting task. |
==External links== | ==External links== | ||
Revision as of 21:15, 16 September 2017
Multics (Multiplexed Information and Computing Service) was an early time-sharing operating system for which has influenced every operating system created since; especially via Unix (the name of which is a play on 'Multics'), which was created by Bell Labs personnel who had worked on Multics, after Bell Labs pulled out of the Multics project.
Multics was intended as an information utility; i.e. a service to which those who wanted information processing would connect, much as people connect to the electric grid for power.
This dictated a number of Multics' features, including the modular structure of the hardware (with multiple CPUs and main memory banks, fully interonnected, and with the ability to take individual units out of service for maintenance, or to simply add additional units as demand increased over time); extremely robust security (so that individual users in a facility open to all comers would be protected from each other), etc.
Technical aspects
In addition to the modular hardware, and robust security, Multics had a number of other major technical features, some commonplace now, but major advances when it was first devices (in 1967). They include:
- A single-level store
- Dynamic linking for libraries, etc
- A command processor implemented entirely in user code
- A hierachical file system
- Separate access control lists for each 'file'
The single-level store architecture of Multics was particularly significant: it discarded the clear distinction between files (called segments in Multics) and process memory. The memory of a process consisted solely of segments that were mapped into its address space. To read or write to them, the process simply used normal instructions; the operating system took care of making sure that all the modifications were saved to secondary storage (disk).
In modern UNIX terminology, it was as if every file were 'mmap()'ed; however, in Multics there was no concept of process memory, separate from the memory used to hold mapped-in files: all memory in the system was part of some segment, which appeared in the file system; this included the temporary scratch memory of the process, such as its kernel stack, etc.
Multics today
Multics is dead. There are no systems running it today (the last one was shut down in 2000.
There is however now a working SIMH-based emulator for the Multics DPS-8/M hardware, and with most of the source code still extant, it is now possible to experience the Multics computing environment.
Reviving Multics?
Porting Multics to alternative hardware would be a worse-than-Herculean task: the design is not well-suited for porting. It used specialized hardware built especially for it, which had many features which do not have exact analogues on any other platform today. In addition, the word length of the machine (18-bit half-words) is explicitly included in many variable declarations in every source module.
Even if that could be overcome, Multics was written in PL/I. There are no PL/I compilers available other than commercial ones aimed at large enterprise systems, and which aren't getting any cheaper. The lack of a free Unixland PL/I compiler inhibits any porting task.
