Secure Unix ancestor KSOS did type safety before Rust made it cool

For the first time, the source code of KSOS, backed by the US Department of Defense in the late 1970s and 1980s, is available to the public in the archives of The Unix Heritage Society (TUHS). TUHS volunteers preserve the historical source code and documentation of the original UNIX – or as much of it as is left. A few days ago …

[Jou (Mxyzptlk)]

"Clearly, executives back then had longer attention spans."

Thank you for the bite! Currently the attention span is narrowing TikTok and Coub videos. (Edit: Or a single-page powerpoint presentation)

[David 132]

Re: "Clearly, executives back then had longer attention spans."

A single-page Powerpoint? Not to go all Four Yorkshiremen on you, but the execs you know are clearly better than the ones around here; I was going to say "a single Powerpoint bullet item", but that'd probably be too long-winded for them; a single smiley- or frowny-face emoji would be about right for their "executive summaries".

[Jou (Mxyzptlk)]

Re: "Clearly, executives back then had longer attention spans."

⦿    $

(The post is required, and must contain letters.)

[jake]

Interesting.

Ta for the heads-up.

I worked there in the late 70s to the early 80s. I'll have a dig thru' my ancient archives and see if I have anything to add to their collection. Somehow I doubt it ... security was pretty tight at Ford on Fabian back then. Walking out with a tape or even a listing was probably a shooting offense.

[MarkMLl]

Nice find

Regrettably, reliable information on the original Modula is scarce: about all I'm aware of is https://www.research-collection.ethz.ch/entities/publication/f94b0c0c-ac24-4c2c-b88b-31c9a0bd902f which is dated 1976.

Compared with Pascal, it loses its predefined I/O: which was enormously problematic since WriteLn() etc. needed to be defined in the compiler.

It also appears to define that structured parameters were completely opaque across modules: an undeniable improvement in robustness, at the cost of substantial extra code for what we'd now call "getters" and "setters".

Pascal's "dangling else" issue is solved by using the same type of syntax as Modula-2. Wirth never attempted to use- and possibly wasn't aware of- the hack in ALGOL-63.

Compared with Modula-2, it lacks the well-thought-out rules for "compatibility" and "assignment compatibility" which potentially leaves it about as fuzzy as is Pascal.

It does have to be said that some of the problems inherent in available Pascal dialects are arguably the result of ill-considered "improvements" in the Borland and UCSD implementations, for example the way that a loop control variable has no defined (i.e. reliably predictable) value on completion even though it is in scope... unless a break has been used in which case the value is reliable.

But the fact that Wirth was working on successor languages only about five years after releasing Pascal says a great deal. As does the fact that the surviving Pascal community refuses to recognise that even Wirth appeared to regret some of his early design decisions.

[david 12]

Re: Nice find

five years after releasing Pascal says a great deal.

It says that Wirth was a language developer, and his interest was in developing languages.

He was good at it -- for example, his decision to include "write" in the compiler is now emulated in the c compiler I use, although it implements functions like that "as if" they were library functions.

[MarkMLl]

Re: Nice find

Pascal's implementation of Write(), WriteLn() etc. in the core language, without having support for indeterminate types and varying numbers of parameters ("polymorphic" and "variadic" in today's terms), and without support for the : separator Wirth used to indicate the desired formatting, was an utter disaster, since it meant that (a) only a core language developer could maintain those functions and (b) developers of extension modules (classic example: to support complex numbers) could not use the same format.

If you look at it in the context of modern core languages which /do/ have polymorphism, variadic parameter lists (or at least arrays), and possibly decent macro and/or generic capabilities: yes, flexible WriteLn() etc. is very nice to have. But the maintenance problems of that type of design decision were understood in the early 1960s, and after trying it in Pascal Wirth recanted in his later languages.

By all means: find a way of adding arbitrary separators etc. to the core language, provided that it doesn't impact the compiler efficiency. By all means, find a way of generalising variadic and polymorphic parameters. But do so in a way that non-core developers can use in their own compilation units, since that both keeps them happy and reduces your own maintenance burden... and make sure that the compiler still fits in memory.

[Chris Gray 1]

Re: Nice find

My old Draco language had read/write language constructs, but they ended up not being used much. Not a lot of text I/O happens in production anymore, I expect. (Am I wrong about that?) Their usefulness would, I expect, be proportional to how much programmers can insert themselves into the activity. Pascal's read/write system made it almost impossible to use them for interactive (text terminal) I/O - my recollection is that that was one main issue with them.

My new Zed language doesn't have built-in I/O functions. What it provides is a very comprehensive "ioProc" facility which allows the creation of powerful text output facilities. Each of the non-fixed parameters to such a call (Fmt/FmtN/FmtS is the standard provided one) has syntax allowing formatting codes, overall field width and a precision value. Skip the ones you don't need. Since it is implemented by programmer-provided code that runs at compile time, it can look for custom formatters attached to the types of values given to it, and use them with the same options. So far it has worked out very nicely. Add to that the ability to create, at compile time, custom formatting procs for the programmer's types, and it becomes almost magically easy to get nice output from very little explicit source code.

Then I wanted to see if even fancier was possible, and made my DispAcc facility (runs all at compile time, but the end result is reasonable native code for the final user code). DispAcc (Display and Accumulate) does tabular accumulation and display of vectors/arrays of structured data. All with the user programmer having to do little more than specify a string describing what the columns should look like. A friend said "Chris, that's application programming, not compiler work!", so the excuse of "I wanted to see if I could" had to be produced. :-)

And, if that isn't enough, one can always write user-defined constructs to do things differently. So far I've used that to write a list iterator to go with the list generic, and a "StringCase" construct which does a 'case' statement with string keys.

One advantage of an entirely new general purpose programming language is that no "AI" has ingested any code written in it. Certainly nothing more than a few examples...

[Phil O'Sophical]

Re: Nice find

Compared with Pascal, it loses its predefined I/O: which was enormously problematic since WriteLn() etc. needed to be defined in the compiler.

IIRC Wirth's original Pascal didn't have WriteLn(), only Write(), and that was implementation dependent since it relied on the OS file implementation(s). Most real implementations of Pascal added WriteLn() in a library, not least because the lack of variadic functions meant that you couldn't write WriteLn() in Pascal.

[MarkMLl]

Re: Nice find

But initially Pascal supported neither libraries nor ways of extending the language using inline assembler, so the only way of implementing WriteLn() was by building it into the compiler. The input and output media was fairly well standardised: cards etc. as declared by the control deck wrapped around compilation and execution.

Pascal did get to support include files and other $-prefixed directives fairly early, which were arguably the legacy of Wirth's experience with a Burroughs mainframe at Stanford. That machine did as well hew to the ALGOL-60 standard and ignored the change in the -63 revision, hence my earlier quip that Wirth might simply not have known about it.

I don't know where completely-separate compilation (i.e. not relying on $include files) originated, but I believe that it was supported by the IBM Mainframe that replaced the Burroughs one at Stanford.

In any event the industry owes a substantial debt to Wirth for the type-safe parameters introduced in Modula-2 (but not, I believe, in the original Modula). Even if most language implementers didn't go to that degree of trouble.

[thechipmunk]

Other Secure OS's

way back in the mists of time we picked up a Unix like OS called TUNIS.

It was from the University of Toronto and written in Concurrent Euclid.

Euclid was originally designed as a "provable" language and there was work done on a provable B2 secure version of TUNIS.

Sadly at the time the conventional wisdom was that Unix and Unix-like OSs were dead and it would be Windows everywhere.

Some times it seems like computer science in the days of paper reports has just about completely disappeared but for a hand full of high profile projects.

[Liam Proven]

Re: Other Secure OS's

> way back in the mists of time we picked up a Unix like OS called TUNIS.

Oh, excellent!

I know of TUNIS [I always tend to spell it "tunix" for obvious reasons) and I am very curious about it. All I can find are some old research papers.

I have mentioned it on El Reg several times:

2022 --

https://www.theregister.com/software/2022/03/29/the-weird-world-of-non-c-operating-systems/412857

2024 --

https://www.theregister.com/software/2024/02/12/the-ever-growing-problem-of-ever-growing-codebases/1036034

2025 --

https://www.theregister.com/software/2025/11/10/ironclad-os-crafts-unix-like-kernel-in-ada-and-spark/541310

Do tell me more. :-)

[tango-golf]

Tom here - thanks for highlighting the work of the early infosec researchers, especially those at Ford Aerospace and Logicon. I've asked for a footnote, but until it appears...

I released an old tarball of the source code that was preserved by fellow KSOS-32 developer Jeff Makey. Jeff preserved the original copy (on tape, IIRC) back at the end of the project, and I've just kept that file in my archives waiting for the proper place to keep and preserve it.