[TUHS] Hypothetical: Could MULTICS have been written in C, if available?

[Dan Cross via TUHS]

[This is really better on COFF; TUHS to Bcc:]

On Sat, May 23, 2026 at 5:12 AM steve jenkin via TUHS <tuhs at tuhs.org> wrote:
> I'm not criticising MULTICS, I couldn't have come close to what they did:

Note: it's Multics, not MULTICS.

>         with what they had, PL/1 & GE-645 hardware,
>         they came up with a working design that had decades of use
>         including 'Security' with many features, like file systems, now standard.
>
> They started with very large budgets, many people and 'stretch' goals - always red flags for projects.
> Perhaps they suffered "Second System" effect and over-designed it - but this isn't a critique, just a hypothetical on the impact of language choice.
>
> The project delivered, it was far better software than IBM OS/360 and gave credence to high-level language kernels & designing for security.

I don't think Multics was trying to compete with OS/360 at all: the
latter was a batch system, Multics was a timesharing system.

Melinda Varian's (excellent, highly recommended) history of IBM's VM
system (https://www.leeandmelindavarian.com/Melinda/neuvm.pdf) goes
into some detail here: from IBM's perspective, they fully expected to
get the nod for project MAC and Multics, going as far as to set up the
Cambridge Scientific Center in Tech Square in anticipation of
supporting that work. But project MAC reacted badly to the 360
announcement, in particular, the lack of planned "address translation"
(read: virtual memory) hardware; something that Doug has mentioned
here in the past. A meeting was arranged between Fernando Corbato and
Gene Amdahl, designed to put oil on the troubled waters; Corby tried
to impress upon Amdahl the importance of virtual memory for
timesharing, and Amdahl told Corby to get bent. Project MAC gave the
nod to GE, and IBM was apparently rather shocked by the loss;
ironically, the 360/67 was announced shortly after.

Anyway, if anything, IBM started work on TSS to compete with Multics;
now THAT was a second system and never really gained much success: VM
was far more popular.

> IBM was first to prove Software Quality was secondary to Marketing for product sales.
>
> Ken & Dennis spent years coming up with C, slowly evolving it to meet their very precise needs: small, efficient & performant.
> Everyone but MULTICS & Burroughs opted for assembler, if they even built a full O/S, not just program loaders.
>
> Thinking of rewriting the kernel in non-assembler was a major invention - a significant research outcome.
> I don't believe we'd have had C without Unix, especially rewriting the kernel.
>
> Doug worked on the PL/1 compiler, from memory, and certainly on MULTICS and might have a view:
>
>         could something like C have improved MULTICS or helped it's success in the marketplace?

I think John was spot on in his response: Multics was very tightly
coupled to the GE-645, H6180, DPS/8m line of architectures. It was
written (mostly) in a high-level language because that was more
productive and less error-prone, but it wasn't portable in any
significant sense, and that hardware architecture was a dead-end.
Being written in C wouldn't have helped that.

Ironically, if it had been targeted to the S/360, it might have been
portable to other machines; at least it would have had power-of-two
data sizes and byte addressing.

> [snip]
> After SEL4 / L4.verified, do we still think "You can't write a 'secure' kernel in C"?
>
> The Verification was a huge effort, far more than writing the kernel.
> Perhaps another language would've lessened the effort, though at what cost?

"Cost" is the key here. You can absolutely write a 'secure' kernel in
C, but the key design question is, is the effort required to do so
worth it? Or is some other language available that lowers the cost?
Bear in mind that costs are abstract; it's not just programming effort
required to avoid bugs, but also expertise in the language, quality of
the compiler and its output, and surrounding tooling.

The SeL4 experience is not representative. Verification covered a
restricted subset of system functionality (I dimly remember that they
cut out DMA), and involved translation into Haskell.

Moreover, "secure" is not well-defined in this context. seL4 wasn't
verified to be "secure" in all respects; rather, verification showed
that it operates correctly with respect to its specification, and that
the security properties in that specification hold.

Back to Multics, I'll wager cookies to cake that in aggregate it has
plenty of buffer overruns, race conditions, and straight-up logic
bugs. What makes Multics more "secure" than Unix is the overall
architecture (aided and abetted by the hardware's ring architecture)
and overall approach, which emphasizes least-privilege, and so on. But
it surely has bugs; presumably at least some of those could be
leveraged to increase a process's privilege level: entire categories
of security attacks have been discovered since Multics was designed.

> We can't change history, the MULTICS experience & the Bell Labs management reaction was necessary for Unix to begin.
>
> Doing kernels on tiny machines forced a very compact, crisp language design, which was then tried 'everywhere', working incredibly well.

I would say that doing _compilers_ within the limitations of those
early machines forced a compact language.

> [snip]
> Why was UNIX written in C instead of PL/1?
> Multics was written in PL/1 which is equally capable and was more mainstream than C.
>         <https://www.quora.com/Why-was-UNIX-written-in-C-instead-of-PL-1-Multics-was-written-in-PL-1-which-is-equally-capable-and-was-more-mainstream-than-C>

Trying to squeeze a full PL/1 compiler onto a PDP-7 would have been
akin to putting ten pounds of nuts into a five pound bag; assuming
self-hosting was a goal, BCPL was decently expressive, and B obviously
fit on the machine available. The B -> nb -> C transition came about
from that, by which point I suspect few people were terribly
interested in a PL/1 compiler.

There's also a matter of taste.  I don't know, but I never got the
impression that PL/1 was a _popular_ language with the Unix folks
after Multics. Perhaps Doug or Ken can comment?

        - Dan C.