Multics resurrected: Proto-Unix now runs on Raspberry Pi or x86 Seminal time-sharing OS Multics - the Multiplexed Information and Computing Service - has been resurrected in a new simulator. As The Register reported in 2011, Multics' sprang from MIT's decision to eschew an IBM mainframe, buy one from GE instead and write an OS for the machine. The operating system's source code was …
Some years ago, when there was a plethora of super-minicomputer company manufacturers, one of the leading lights was Prime Computers. Their operating system, Primos, was based upon Honeywell's development of Multics for super-minis.
Primos was a class act and well ahead of its time in many respects.
I wouldn't dismiss Multics out of hand.
Wow - PrimOS. That brings back some memories. Interesting systems, and like many they had some good points and some really infuriating ones as well. Certainly easy enough to use but at the time I used them there were already lots of grumbles about lack of software support with vendors abandoning PrimOS ports in favour of pretty much anything else.
In the late 80s, early 90s, the company I was with was moving offices. It ran on a PR1MOS-based COBOL suite, and we needed new hardware to cover the move - I can't recall the model. No bother, said Prime, it's all yours for a mere £2million. My boss at the time, who knew full well the writing on the wall for Prime said "Think again." He ended up getting two systems and paying £900k. It took another 10 years to port the COBOL to another platform. Unfortunately that platform was Dynix/ptx....
My memory is that it was originally on a GE-645 computer on the top floor of tech square at MIT. I remember seeing the machine there. We used to log on to this machine remotely. I still have the instruction manual for this machine.
Then Honeywell bought out the GE computer department - many stories about the early development times.
I don't think so. Take a look at the comp.sys.prime FAQ entry on Primos.
TL;DR version: written at a NASA research centre because they needed a time sharing system; originally called DOS(*); in the public domain because it was done with US government money; the company was set up to sell hardware running the OS; finally called Primos when V mode came along.
(*) As were most OSes in those days.
I was there at the time, I was the initial customer for a distributed Prime WAN deployment in my country, that went global; subsequently I was processed through Prime's internal SE course, as a "reward", and worked as part of the benchmarking team on a number of US government tenders, including classified ones.
The Honeywell origins were freely acknowledged if anybody asked, mostly, they didn't.
Quite a lot of OSes were called OS.
Thanks for the correction.
The thing that struck me about reading the post was how organized Prime seemed, possibly as a result of having its core group all from the same originating company (I wouldn't call Honeywell a parent as I don't think they had any involvement in Prime).
But the game changed and they made some wrong moves and they were out evolved by Intel and MS.
Of course what has happened once can happen again.....
Prime's first OS was called RTOS, for Real-Time Operating System. It was written by Prime's founder, Bill Poduska, who wrote the first assembler for Multics. DOS came next, and then later, DOS was used as the bootloder for PRIMOS. Beginning with Revision 17 of PRIMOS, most of the OS was re-written in a subset of PL/I, and the Primos Analyst Training Class notes included pages photocopied from the Multics Systems Programmers Manual.
RTOS is lost to time. I have the DOS source code, the source code for PRIMOS Rev 18.1 and Rev 19.2. As Bill Poduska himself described, it's "Multics in a Matchbox".
One of my earliest memories from the late 1970s is my dad driving along the M4 from Heathrow and seeing the elevated neon signs for Data General and Trico. I knew even then that windshield wipers were not my calling, but sadly, by the time I was ready for Data General, they had long since disappeared. But I credit that sign with laying a seed of interest in computers.
We had access to a Prime run by the Home Office. Its main use was to run a Lockheed bibliography database. It was possible to write well tuned queries for that, a characteristic which Google, Amazon and eBay seem to remorselessly root out of their query engines. The responses were in the form of references to microfilms of the original papers which were supplied to the labs which used it. Elsevier would have a blue fit if that were done today. The database was written in FORTRAN; for some reason a query managed to get it to start regurgitating the source code but I never managed to get it to repeat that trick.
We also had Pascal available. I can't remember what use I made of that but I must have done. We got our Onyx Unix box a little later and I sacrificed one of the TTY ports to connect to the link to the Prime (we must have had some sort of multiplexer on the Prime link). We didn't have tip, cu or the like on the Onyx so I explored the possibilities of fork() (and, indeed C which was new to me at the time) to write a simple equivalent so I could get on to the Prime from my lab instead of having to go down to the library. If I'd just been wanting to use the Prime for a literature search I'd have had to go to the library anyway to use the microfilm.
Again, thanks for a reminder of times gone by.
As I was told at the time, the MOD spent an unfortunate amount of time deciding on a minicomputer to standardise on. This being a Prime model which promptly went out of production.
I missed out on the Primes. When I started work (1990) they had just been removed and the ground floor of our building was a dark warren with unexpected holes in the floor. There were still people who bemoaned losing a "real" computer - even though the 386PC desktop was quicker, not shared, and cost less than a years maintanance.
This is the same realm that built a big new building to house a new Cray. Had to be big because the new computer was a hundred times more powerful than the old one, and that was quite big enough. Last time I saw the place the new computer was installed in the lobby, and the cavern was used as a super-chilled typing pool...
The first commercial mainframes I worked on (in the 70s) were Honeywell 36-bit machines running GCOS (originally GECOS for General Electric). They also had the ability to run Multics (and we had the manuals), but there was no commercial software (such as COBOL compilers) available for it.
All customers got the source code for the OS - it was on microfiche. This enabled you to write and implement your own patches, which we did. I think some universities ran Multics, but whether they got the source code, I can't say.
Often, mainframes came with source code. It was sold with the hardware, was very tied to the hardware, there were no mainframe clones on sale, and very few could build one (and have the space to host and run it). Licensee were well known, and giving access to code could wasn't a big issue, and customer may have needed to personalize it. Also, big money was made selling the hardware, not the software.
Illegal copies of software and IP became a much bigger issue later, with the advent of minis and personal PCs, ISV (software only companies), more competition, and off-the-shelf software. Now money was made selling software, not the hardware.
It's no surprise the FOSS movement was born in universities among people used to have access to the OS and application code on mainframes.
Certainly my Uni ran it (Brunel, west London, c1980) and I used to spend hours in the computer centre trying to learn how to program. Now, finding out that I could recreate the experience with a Raspberry Pi seems to illustrate just how far we've advanced in such a relatively small length of time.
I'm just kicking myself for throwing out my original "Multics Pocket Guide" at the last house move ...
IN 1974-75 IBM provided the source code for their mainframe OS to some customers. A university I worked at then had it on microfiche. Somewhat later, a large insurance company in Vancouver had it, too.
And Burroughs provided source code for the MCP in that era, as well.
In fact the hardware story is somewhat more complex.
GE originally produced the 635 and its OS GECOS-3 in the early 1960s. When MIT were looking to create their new OS they looked around for hardware and GE were prepared to custom-build a processor with segmentation and paging hardware as required; IBM were not.
Hence the GE-645, which was the first Multics CPU.
Later, GE developed the 6000 series to run GECOS: several models including 6050, 6060, 6070 and 6080 AIR; the "even numbered" ones having an extended instruction set - EIS - for commercial programming: it had instructions like MVNE (Move Numeric Edited) which could take a binary value and format as ASCII, complete with currency symbol, commas for thousands, decimal places and check suppression characters - RISC it was not.
But the 6000 series did not have the segmentation and paging hardware necessary for Multics; moreoever, among other recommendations of the USAF Tiger Team looking at Multics security, was that the rings should be implemented in hardware, rather than in software as on the 645.
Enter the 6180, which had the segmentation and paging hardware AND hardware rings (8 as opposed to the 64 on the 645) and fixed-size pages.
GE sold their computer business to Honeywell around 1971, later Multics processors were the Level 68 and DPS-8/70M.
It was only internal politics within Honeywell which killed Multics; by 1984 they had also acquired Xerox's computer business, so now found themselves with 3 mainframe OS's: GCOS (the E was dropped as part of the agreement with GE, although much of the documentation kept it for some time), Multics and CP-6 (originally CP-V when owned by Xerox).
I'm not sure about the 70s, but by 1980, when I began working on Multics there certainly was a COBOL compiler (I wrote an emacs programming mode for it for a UK customer) and quite a bit of commercial software, including one of the first relational database systems, MRDS.
I still miss Multics.
r 19:24 0.172 65
edm hello.cobol
Segment not found.
Input.
000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. HELLOWORLD.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100500 DISPLAY "Multics rulez, UNIX droolz".
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.
.
Edit.
w
q
r 19:24 0.128 4
cobol hello
COBOL, Version 5.4
r 19:24 0.477 206
hello$HELLOWORLD
Multics rulez, UNIX droolz
hello$HELLOWORLD: Run-unit hello$HELLOWORLD terminated (line 18).
r 19:24 0.036 6
I was around during the GECOS-III and HW and then Bull lines. I did a bit of C work on Multics and I think it had a functioning nroff system for doing typesetting - this back in the late 70s.
Since my little company was somewhat deeply involved with the GCOS (Honeywell) transition I do remember the angst about the neglect for the leading edge features of Multics:
- all files were memory mapped
- ring security enforced at the hardware level
- virtual associative memory
Of course all of this had a lot of overhead and didn't sell well into the corporate suites.
Maybe it will actually rise from the ashes in the world of IoT!
> Does Multics have any useful features that are not present in modern OSes
There was the "cookie" program. It would seize control of your terminal and type write I wanna cookie and wouldn't let you continue with your work (or play) until you typed "cookie".
The original virus?
Yes, because computer weren't born at GCHQ predecessor, right? <G> And most universities refused military and government funds for their researches, right? Guess the various agencies knew exactly what was going on the relatively few mainframes working back then....
@Voyna i Mor: "Given access to the source code and the ability to modify it, you could in principle be very sure of that."
Have you read Ken Thompson's classic paper "Reflections on Trusting Trust"?
"Does Multics have any useful features that are not present in modern OSes ?"
Its virtual memory implementation comes to mind: in Multics, "files" were really persistent memory segments, i.e. all files were "memory-mapped" in Unix-parlance.
https://nbonvin.wordpress.com/2008/02/05/review_the_multics_virtual_mem/
The concept was not without problems of its own (see the linked article above and the articles linked therein); but given today's availablity of reasonably fast, persistent mass memory technologies I think that exploring direct mass memory access while doing away with traditional file I/O might well be worth exploring once more.
Multics was written in a high level language (PL/M IIRC, IE "Programming Language/Multics") but the compiler was hand written.
In hindsight it might have been better for the team if they developed V1 of the compiler using one of the "compiler compiler" tools of the time, then fed a copy of the compiler through itself with the optimize flag on.
The virtual memory system was impressive. IIRC it kind of did execute in place, not needing a lot of address fixing during the load process. It also made code sharing very simple.
Mines the one with a copy of "RW Watson, Timesharing System Design Concepts" in the pocket.
When I arrived at MIT in 1969 the decision to use a high level language to design Multics was still controversial. I went to grad school in a place that ran a Multics system (it was Honeywell by then) and it was still mostly PL/1. The Pascal "compiler" used for classes worked by translating Pascal to PL/1 - I was the first person to get the Jensen/Wirth Zurich compiler to compile itself. (Sets were done assuming a 60 bit word.)
It is hazy now, but I recall that file protection was a lot more flexible than on UNIX, with access control lists implemented a lot more cleanly than anything else I've seen.
I thought that the compiler was (eventually) written in PL/1. (It used to be called NPL for New Programming Language until the National Physics Labs complained.) Wherever the compiler was slow they optimized the compiler so things got better and better. There was a compiler switch for generating optimized code but they discovered that compilation times were faster with optimization enables so they removed the compiler switch and made all compilations optimized. The only code not in PL/1 were device drivers and bootstraps etc.
There was an early decision to do all of the code in PL/1. They figured that they would lose a factor of 2 by not being in assembly but gain an order of magnitude by being able to manage the code base. Best decision - every time someone complained about slow generated code they fixed the compiler and everyone benefited.
We stole the hierarchical file system for the Dartmouth Time Sharing System. We didn't have hardware for paging so we couldn't steal their memory system.
MULTICS was a great system before its time.
The much under appreciated IBM TSS/360 operating system also had memory-mapped files, decades before the FS-inspired System/38 (iSeries these days). Basic problem with TSS was that it was well before its time, and the S/360 model 67 hardware was never adequate to run it. While it was possible to get a 32-bit addressing version of the model 67, no S/370 models offered it, so customers such as General Motors who had built their early automobile CAD system on TSS were unable to migrate TSS to S/370 and had to rewrite/restructure their CAD software to run on the 24-bit virtual of S/370, and also lost the ability to have memory-mapped files.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
