MIT Releases the Source of MULTICS, Father of UNIX

mlauzon writes "Extraordinary news for computer scientists and the Open Source community was announced over the weekend, as the source code of the MULTICS operating system (Multiplexed Information and Computing Service), the father of UNIX and all modern OSes, has finally been opened. Multics was an extremely influential early time-sharing operating system and introduced a large number of new concepts, including dynamic linking and a hierarchical file system. It was extremely powerful, and UNIX can in fact be considered to be a 'simplified' successor to MULTICS. The last running Multics installation was shut down on October 31, 2000. From now on, MULTICS can be downloaded from an official MIT site (it's the complete MR12.5 source dumped at CGI in Calgary in 2000, including the PL/1 compiler). Unfortunately you can't install this on any PC, as MULTICS requires dedicated hardware, and there's no operational computer system today that could run this OS. Nevertheless the software should be considered to be an outstanding source for computer research and scientists. It is not yet known if it will be possible to emulate the required hardware to run the OS."

Comment removed

[account_deleted]

Comment removed based on user account deletion

Hey Microsoft! Read the source and weep...

[toby]

Btw, it's "Multics" not "MULTICS".

Probably the best source for Multics-related information is this site. [multicians.org]

Re:Too Complicated to Run?

[Fred_A]

Pretty much the same thing that makes ZX Spectrum software "too complicatded" to run under today's most sophisticated hardware. i.e. it's not meant for that hardware and therefore won't run. Unless you write an emulator first (like one was written for the Spectrum) and run a binary image of the software on that.

But then we need to find a binary image of the software and we only have the source. Is this a chicken and egg problem ? :)

Re:emulators?

[Anonymous Coward]

I imaginet one of the machines in the simh simulator can run this...

Re:Imagine...

[BobNET]

Already some poor government contractor is being asked to implement just that very system.

If they're a government contractor, I'm sure they're anything but poor...

MESS

[Weaselmancer]

It's MESS [mess.org] you're thinking of, not MAME.

Re:Too Complicated to Run?

[Akaihiryuu]

It sounds like it was written for the hardware of a particular series of mainframes and will not compile on anything else. The further back you go, the less abstraction there was, and the more code was written "to the bare metal" so to speak. Give it a week, then there will be a Slashdot article: "Multics ported to i386". There is NO reason that it can't be ported to any architecture, given enough interest. Someone will port it, just because they can.

Mod parent up

[Raul654]

For those of you who missed the reference, ding! [wikipedia.org]

Re:emulators?

[eyrieowl]

Can I have the $1,000,000 if I simply show you I can without doing it? http://en.wikipedia.org/wiki/Universal_Turing_machine [wikipedia.org] I prefer check, but I'll also take cash or wire-transfer.

Re:emulators?

[Hatta]

Can I assume an arbitrary amount of storage? If so, Alan Turing [wikipedia.org] would take that bet.

Comment removed

[account_deleted]

Comment removed based on user account deletion

The special hardware exists on 386s and later

[davecb]

There are two hard parts

1. Rings and ring-crossings, which are supported in intel hardware since the 286/386 era, and
2. Long words, longer than 32 bits.

Adresses and ints were 36 bits, longs were 72, and people used the 8th and 9th bits in in bytes for control and meta bits when manipulating raw terminal input.

Expect most of your problems will be with porting things like bit_offset_ entry (ptr) returns(fixed bin(24)) reducible

--dave ([e-mail]) c-b

Re:Father of Unix?

[steve54]

Ken Thompson & Dennis Richie worked on MULTICS (MIT and Bell Labs were both involved in the project). After Bell Labs dropped out of the project, Ken & Dennis created Unix partly as an effort to reproduce the good stuff they were missing.
MULTICS and GCOS both ran on variations of the same hardware (The G in GCOS used to be GE as in General Electric -- Honeywell kept the acronym when they bought GE's computer operation).
The GCOS field in /etc/passwd was to support a batch job submission subsystem. This field connected your Unix account and your GCOS account.
The MULTICS is not an acronym but the gag acronym I heard was Many Unbelievably Large Tables In Core Simultaneously (that's what I heard -- http://www.multicians.org/multics-humor.html [multicians.org] has it as Many Unnecessary Long Tables In Core Simultaneously).

Re:Too Complicated to Run?

[Anonymous Coward]

There's even someone working on a GNU Compiler Collection (GCC) frontend for PL/1. http://pl1gcc.sourceforge.net/ [sourceforge.net]

Re:The real legacy of Multics

[fm6]

Multics was, fundamentally, a research OS

Not true. Two of the three partners in the project were Bell Labs and GE. Bell Labs wanted an OS their researchers could actually use, and pulled out when they decided that the project wasn't going to come together in a useful time frame. GE's mainframe division wanted a new OS to differentiate their products from other mainframes, and went on to sell a small number of MULTICS-based systems. Or to be precise, Honeywell, Groupe Bull, and NEC, who owned the former GE mainframe division in turn, sold them. The last MULTICS-based commercial system was discontinued in 1987. Doesn't sound like a "research OS" to me.

Have a look at http://www.multicians.org/myths.html [multicians.org]

Re:Not "simplified"

[SuiteSisterMary]

To make it even more amusing, meditate on the fact that most of what was chopped out of MULTICS to make UNIX was....the security related stuff!

Yes, UNIX is actually a secure operating system with the security removed.

Re:emulators?

[orangesquid]

Nope. The I/O hardware that the Level/68 system used was an extremely complex independent beast. (Think of SCSI (small computer systems interconnect) on steroids... since, uhh, Multics wasn't a "small computer system," but quite the opposite.) The documentation that survives is widely scattered; the few (insufficient) pieces that have been scanned and can be found on the web are at bitsavers [bitsavers.org]. Much will likely have to be reverse-engineered.

I've been working on an emulator [orangesquid.net] for a number of years. This article very good news, because it will make it easier for other people to get involved. (Note: don't bother trying to play with the emulator, because it is very... non-functional thus far. If you're interested in helping out, please do read everything at multicians.org, start following alt.os.multics, skim through everything on bitsavers, and then drop me a line *grin*).

Re:A good source of Prior Art

[Bozdune]

Actually, the Compatible Time Sharing System (Corbato, et al, 1962 or so) is a better candidate for the father of all modern operating systems. CTSS, for example, continued to provide reasonable response to the other users even when a process went spinning in a tight loop. This is something that Windows still hasn't solved.

Re: Too Complicated to Run?

[uucp2]

In current Unices, mmap can map the same file with different permissions from process to process.

True; this way you can attach a shared library into your code ("text") and data segments. However, if you think about the wikipedia article, you see that the Multics model differs from Unix method substantially. Process A can request pieces of Process B linked into it, then call the linked in piece of code and actually read and modify the pages which belong to Process B (using the code of Process B). You can't do that in Unix.

You can achieve the same functionality by using shared memory, but then Process A's code could access Process B's data, which is quite different in security point of view. It is a bit like a system call, but instead of calling the kernel, you are calling another process.

Re: Too Complicated to Run?

[davecb]

You're right, it's almost all in PL/1, with very approximatly the same amount of assembler as Unix. --dave

Emulation of GE 36 bit hardware has been done .

[Anonymous Coward]

BULL sells a machine today that runs GCOS8 on an emulated platform .
They use an Itanium platform and it runs at least as fast as the native platform .
Go to BULL-s homepage and search for HELIOS , GCOS system used to run on
GE6000 machines very similiar to the Multics machines only the virtual unit
was different . I think GCOS ran on GE635 and Multics used GE645 or GE655? .

The last Multics installation

[mu51c10rd]

Rather amusing, the last Multics in use was with the Canadian military. See here [ncl.ac.uk].

Re:emulators?

[david.given]

Are you just pretending that you forgot about the GB of RAM that comes as standard on on MacBook Pros, or do you really think that RAM is irrelevant to emulation?

Of course it is. If you've got enough swap. Which you can plug into the Palm's USB connector.

Re:Too Complicated to Run?

[ctzan]

There's a modern PL/I compiler (kednos) that works on VMS.

I've played with it on vms/vax (on simh), but it probably works on VMS on alpha and Itanium, too.

What is funny is how small and fast is when compared to gcc, given all the stories about PL/I being a 'big' language, that needs a compiler 100 times more complex than a C one.

Re:Too Complicated to Run?

[SpinyNorman]

MULTICS era machines did not have many Mb

Indeed. We had a Honeywell Multics system at Bristol University, UK when I was there from '79-'82. The thing was impressively fast (it would compile small FORTRAN programs in no noticble time - type compile command, hit enter, and you got your prompt back), but nonetheless I recall Bristol getting a free HALF A MEGABYTE (a big deal at the time) memory upgrade from Honeywell to address performance issues.

Re:Too Complicated to Run?

[mwvdlee]

Still actively maintaining PL/I code on z/OS mainframes! :)
The compiler is still actively supported by IBM too, though not quite as much as COBOL compilers. Not much new code is written in PL/I in my workplaces, but it still happens on occassion. Either way PL/I is a pretty easy language to learn, easier than COBOL IMHO. Any C programmer should be able to write basic PL/I in a week.

Re:Too Complicated to Run?

[Burrfoot]

As I recall: Multics ran on a mainframe system with 36 bit words (yep, 36 bits) giving you a choice of 6 bit BCD or 9 bit ASCII++ characters, 18 bit half-words used for indexing arrays, etc. 80 bit floating point arithmetic sharing the same general purpose registers as the 36 bit integer registers (2x36 bit registers holding the mantissa + and 8 bit "extension register" used to hold the exponent.) and a powerful but quite different memory map/virtual memory/ring of protection memory architecture. It had a single I/O instruction: CIOC (meaning connect to I/O controller) All that did was wake up the attached I/O coprocessor (the IOC) which executed IO Control programs (a unique language) that you left in main memory. The IOC, by the way also participated in the memory management and ring of protection scheme. Altogether a *different* beast from anything being built today. Portable code? We don't do portable code, Were MULTICS! Sure you could write an emulator -- using a x86, or a Turing machine if you want to. At least you could *START* writing an emulator, but I'll cover any bet you want to make that you never FINISH writing an emulator. -- What happens if I don't have a SIG?