unused0
Multics (as noted above) was written in PL/I.
With single level store, the program pages are mapped in, not copied. Writing to the page alters the disk image. All processes running the same program share the memory pages.
The X86 segmentation facility resembles Multics segments in name only.
https://multics-wiki.swenson.org/index.php/Main_Page
There are also several public access Multics systems up and running.
Many additional languages are available, such as COBOL, FOTRAN, APL, BASIC, Assembler, JOVIAL and others I can't recall off the top of my head.
These hardware features are not found in the current gamut of architectures due to the dominance of the marketing value of being the fasted CPU; these features lower the CPU throughput and also cost valuable silicon space, and the economic value of a secure OS is less then the value of being faster or shinier.
segment User-visible subdivision of a process's address space, mapped onto a storage system file. Each segment is 1MB long, and has a zero address. The term "segment" is used interchangeably with "file" -- except not really: the things that are files in other systems are implemented as segments; also, the term "file" includes multi-segment files, and when talking in terms of COBOL, PL/I, or FORTRAN language runtime objects, one speaks of files. Programs are spoken of as stored in (procedure) segments. Correct use of the terms "file" and "segment" is a sure sign of a Multician.
r 13:41 0.055 7
ls >sc1>system_start_up.ec
Segments = 1, Lengths = 2.
r w 2 system_start_up.ec
Reading the Multics B2 security analysis reveals that the review team did find security holes in Multics which were fixed as part of the review process.
Recently, a buffer overflow vulnerability was found in the Multics CKermit implementation, despite it's being written in PL/I.
Security is hard, and is achieved through good programming, not by (just) trusting tools.
PL/I does bounds checking on arrays, but not on pointers.
The Kermit server allocated an insufficiently large buffer to decompress packets into, and used ptrs to write to the buffer. (Errors 1 and 2: allocation and ptrs)
Later in the code, there is a 'goto state(idx)' construct, with a declaration like 'dcl state (0:6) label init (state0, state1, ....);'.
Which label is jumped to depends on the value of idx.
The 'state' variable was not declared to be state (error 3), so the table is in writable memory, and due to whatever circumstances, is above the decompress buffer.
A correctly crafted packet, when decompressed, will write over the end of the buffer and onto the state array. Later, when the goto is executed, the address transferred has been changed. It is not the case that a transfer can be made into the decompress buffer, as it is not in an executable segment, there are lots of places that could be transferred to, leaving open the possibility of an exploit.
The error was discovered when a particular file transfer would reliably crash the kermit server, and analysis of the crash uncovered the coding errors.
See https://multicians.org/pl1.html for details.