Re: [COFF] [TUHS] man-page style

To explain how this was even possible, you need to know a tiny bit about Multics. It was a 'single level store' system; process memory and files were not disjoint (as in UNIX), there were only segments (most of which were long-lived, and survived reboots); processes had huge address spaces (up to 2^18 segments), and if you needed to use one, you just mapped it into your address space, and off you went. So he wrote his code, and if I in my command process executed the 'TELNET' command, when it needed to open a TCP connection, it just mapped in his TCP code, and called TCP$open() (or whatever he named it). It fiddled around in the networking state (which was in a data segment that Dave had set up in his 'networking' process when it started up), and set things up. So it was kind of doing a subroutine call to code in another process. The security wasn't good, because Multics didn't have set-uid (so that only Dave's code would have had access to that state database) - when they later productized the code, they used Multics rings to make it secure. But still, that was pretty amazing. The key thing here is that nobody had to modify the Multics 'kernel' to support adding networking - the basic mechanisms (the single-level store, etc) were so powerful and general you could write entirely new basic things (like networking) and add them 'on the fly'. What Multics had was quite different from ukernels, but it amounted to the same thing; the system wasn't this monolithic blob, it was layered/modularized, and you could see (and gain access to, and in some cases replace - either just for yourself, or for everyone) the layers/modules. The nice thing was that to call up some subsystem to perform some service for you, you didn't have to do IPC and then a process switch - it was a _subroutine call_, in the CPU's hardware. I don't think anyone else ever tried to go down that path as a way to structure an operating system (in part because you need hardware support), and it's a pity. (UNIX, which would run on anything, killed just about _everything else_ off.) The 386-Pentium actually had support for many segments, but I gather they are in the process of deleting it in the latest machines because nobody's using it. Which is a pity, because when done correctly (which it was - Intel hired Paul Karger to architect it) it's just what you need for a truly secure system (which Multics also had) - but that's another long message.