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.
"Like OS/400 and AIX?"
OS/400 (now "IBM i") is the other commonly cited OS that provides a single level store, and AFAIK the only one still in active commercial use today. (Aegis and KeyKOS are two other, now defunct, examples that I remember OTTOMH.)
AIX OTOH is IBM's homegrown (SysV-based) implementation of Unix and while certainly providing mmap(2) & friends I am not aware that it has a single level store. Not that it would be impossible to implement a POSIX-ish OS on top of an OS based on a SLS (it has, in fact, been done: Domain/OS), but to my knowledge AIX is basically SysV with the usual set of BSD extensions as well as IBM's very own bells and whistles added.
Note that a "single level store" means more than just the ability to mmap files (I had mentioned mmap only as a /very loose/ Unix-analogy); in fact such a system does not have a "file system" in the usual sense of the word at all - just a large, usually segmented, address space or object store that is transparently being made persistent by the OS through writing out dirty pages to permanent background storage as needed.
No need for file I/O to keep data persistent, /that/ is the key point.
FWIW, the concept appears not to be entirely "dead"; while searching Multics references I stumbled on this paper
http://repository.cmu.edu/ece/370/
but I have not yet had time to really digest it. And then there is of course "The Machine", or rather, with quite a bit of luck there will be one day... although "memory centric computing" - while also being built around a persistent main memory is a different and more far-reaching concept altoghether.
BTW, another Multics nicety that I had forgotten in my original post is the fact that Multics segements containing executable code could (being mapped into the address space all the time anyway) be directly invoked and the interface for doing so was IIRC provided and standardized by the OS, thus leading to implicit cross-language compatibility of executable code. No need for FFIs and stuff.
From what I remember about it, its APIs had versioning built into the interfaces. It was designed for live-upgrade.
The components would fall back to the latest version each understood, and as the opportunity arose they would fall-forward to newer versions. I think it's one of those things that is theoretically a good idea, until you start involving humans.
I mentally filed all this under the image of a kitten tangled in string.
I got a job as a student programmer at my university shortly after they replaced their aging Burroughs B5500 (affectionately known as "Bertha") with a Multics system. It felt like the future had arrived. Exotic OS features! CRT terminals! Lowercase characters! No more punchcards! PL/1!
I actually took some heat for one thing I did -- ported a multiplayer "Space Wars" game to work on our Teleray 1061 terminals. The load from people playing the game during prime hours was having a significant impact on system performance. (I had to assure my management that the development had been done on my own time, not on the job).
My similar history involved IBM's VM/CMS. We were able to convince management that by transitioning a Star Trek game from Basic in to REXX, that would give us experience with the new language. On work hours.
And it worked, both ways. The game was functional, and we did learn the language.
Funny, though, how the game development and additions didn't stop once we were declared to have graduated from that particular learning activity . . .
(Nostalgia: I got through the whole post without mentioning Creative Computing and David H Ahl. Until now.)
The Burroughs architecture was pretty advanced for its time, being designed directly to support a high level language and tight access security to variables. I didn't know about the upper case restriction. That sounds a bit austere, even for business use.
Edward Dijkstra wanted one when he watched it compile his program as fast as it was being read in (single pass compiler. Apparently not at ll standard at the time).
There were five Multics systems in UK Universities as I recall, Birmingham, Bath/Bristol (AUCC), Brunel, Cardiff and Loughborough. Typically these were hooked up to Lear-Siegler ADM3a or similar terminals, ours used British-built Insight VDT-1s (who were eventually bought our by Sanderson Electronics).
Of course, as with probably most 1980s computing students we tried to hack it, but unlike other boxes the security was very solid. Social engineering attacks worked the best. Yes, I got into a lot of trouble in those days..
As an aside, Paul Smee was one of the leading Multicians of the time IMO. Sadly he passed away back in 2006 - http://www.bristol.ac.uk/news/2006/5138.html
There were also two non-academic systems: STC (Standard Telephones and Cables) and the RAE (Royal Aircraft Establishment).
The RAE site was the first MLS (Multi-Level Secure) computer system in the UK, as Multics had just been certified to Orange Book B2 level. I constructed the security trials which we conducted for the RAE as part of the acceptance testing.
If I told you any more, I'd have to kill you...
Since you mentioned a name now lost, let me mention another, also an OS wizard: Jim Oma, who was one of the tiny team (about six people) that maintained Burroughs's large systems MCP.
Jim died around 1973; he's long gone and most people have never heard of him. Clever guy!
Unix was meant not so much an anti-Multics as a mini-Multics. Unix had to run on a PDP-7, after all, and then a PDP-11, vs. a mainframe that could have a whole megabyte of memory. In other words, by today's standards, big fat Multics was small.
But it had features still missed. Security was central. It had rings of protection, enforced by the hardware (unlike Unix, it was not meant to be portable). The zillions of Unix exploits that plague today's descendants would not be likely to work in Multics. Frankly reviving it for modern hardware might be a useful exercise in security.
Funny you should mention Multics on Modern Hardware. When I first got the docs on the 80286, I said to myself: "looks like they want to run Multics on this beast". Rings, real segments, etc. Then I started using it and found that the segments were not quite as lovely as they were described (loading a descriptor was slow, and no caches for them). Intel could have fixed this for the 386, but it seems that the Great Unwashed _really_ wanted a memory model just like whatever Vax or SunOs machine they had in school, so they added fairly conventional page-maps as well. The death knell was probably when the folks who thought it was the bee's knees to execute code on the stack led the march to "forget segments" and map them all to one flat (page mapped) address space.
I also recall fighting with a gcc re-target over which of the configuration stuff to control things like stack layout would actually do so, or was "more like guidelines, really". Had to wonder WTF they would do with something like the IBM360 ABI that allowed "bushy stacks" (ala Burroughs) or the Power or Natsemi16032 that supported function pointers that were more than an index of octets in the one undifferentiated memory space.
In summary, Modern Hardware (for some values of "Modern") has at least vestigial support for Multics-worthy security and isolation. Modern Software developers for the most part seem more willing to eat a live toad than accept the constraints (and re-training) that might involve.
Memory pages were required in the 386 because you can't really believe to implement virtual memory at the segment level when segment maximum size went from 64K to 4G (and physical memory was quite limited back then).
That said, segments and pages can work together - just manage virtual memory using pages, and manage software security with segments, but OS designers were still unaware of the security implications, and threw away segments because of the performance issues (exactly because of the security checks performed).
Then came AMD and removed segment support altogether.
"and threw away segments because of the performance issues"
https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options:
PAX_SEGMEXEC
This implementation is based on the segmentation feature of the CPU and has a very small performance impact, however applications will be limited to a 1.5 GB address space instead of the normal 3 GB.
This also used rings but had a very small register set, several of which acted as stack bases.
That mean they could be "slaved" with multiple (hidden) registers in the CPU.
ICL reckoned this would give those registers a cache hit rate 10x that of random data, while being quite simple to engineer. It also meant they could (in theory) provide different price//performance points. Base line has no slaving, more expensive designs have 1 or more slaves. Interestingly the supported data types were part of the ISA but the actual instruction set was not. It was expected to be flexible, with the OS (like the Burroughs 5500) programmed in an in house HLL.
Unlike the 5500 the goal was good support of any major HLL, not just one tweaked to the specific architecture, which raises question of what are the core capabilities you should have in the hardware?
So accumulator based (like an x86) but with the what we would call very strong orthogonality, like the M68K.
For anyone interested
One of the things that's really changed since these machines were built is the massive improvements in chip design and layout software.
What was a bet-the-company project in the late 60's could be an EE class project.
Which?
George 3 ran on 1900 machine, the 2900s ran VME/B (and wasn't there a smaller VME/K?)
The ICL people visited the Multics people during the design phase, but IIRC the Multics people couldn't understand why the ICL people felt that 32 rings were needed. Multics had originally had 64 on the GE-645, but this was reduced to 8 on the 6180 - and only rings 0,1, 4 and 5 were actually used initially although later on something (was it forum?) ran in ring 2 and some of the UK Rainbow book networking software ran in ring 3 (I know this for certain, as I wrote a call gate for the latter). Rings 6 and 7 were sometimes referred to as "outer darkness" as the standard software was not accessible in those rings.
Of course, the 2900 could emulate the 1900. Indeed, in the early 1980s my wife encountered, at BT in South Wales, the "orange Leos" which were ICL 2900s running the 1900 emulator running the System-4 emulator running the LEO emulator running LEO programs for which they no longer had source code.
Oooops.
Yes it would indeed be one of the Virtual Machine Environments that would be the appropriate OS for them.
"the "orange Leos" which were ICL 2900s running the 1900 emulator running the System-4 emulator running the LEO emulator running LEO programs for which they no longer had source code."
OMG It's been ages since I saw an emulation stack like that. I thought they only existed in the financial sector.
Used both Multics at STC and VME when STC bought out ICL.
There is already a G3 emulator and the current VME - still in use by some customers actually runs under emulation on Intel hardware - whether this will ever by generally released is another matter.
ICL seemed to by very good at emulation - with ICL1900 and System4 being ones I saw - there were rumours of a 370 emulator but denied.
What was interesting about the emulation was the fact you had multiple instruction decoder boards to allow the different instruction sets to run as well as some intelligence in the various peripheral controllers to allow the newer hardware to work with older OS.
From memory there were several variants - DME which allowed the new hardware to pretend to be the old hardware - just running a lot faster, CME which allowed concurrent emulation with the hardware effectively time slicing between the two instruction sets - useful when moving a workload from the old platform to the new one and I have some bitter memories of using BMEEP which allowed one VM to run under a different instruction set
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
