9 ms·

This is why I'm interested in old, now mostly obsolete/dead operating systems. No one has really felt free or able to break out of the UNIX mould, since. And

by retrac 4y ago

This is why I'm interested in old, now mostly obsolete/dead operating systems. No one has really felt free or able to break out of the UNIX mould, since. And we've been using the mould for a long time. It wasn't always so uniform. There have been some craaaaazy things out there, that we simply never see today because it doesn't fit. Off the top of my head: * ITS (of PDP-10 hacker fame) - processes could debug and introspect their child processes. The debugger was always available, basically. The operating system provided support for breakpoints, single-stepping, examining process memory, etc. Whatever part of the system manages processes, is the natural place for the debugger, really. Some of this has been brought to Unix systems recently, but you still can't trivially freeze a process, tweak a few values in its memory, and resume it as an integrated part of the operating system. Why not? It seems very basic to an operating system, now that I think about it. * KeyKOS (developed by Tymshare for their commercial computing services in the 1970s) - A capability operating system. If everything in UNIX was a file, then everything in KeyKOS was a memory page, and capabilities (keys) to access those pages. The kernel has no state that isn't calculated from values in the virtual memory storage. The system snapshots the virtual memory state regularly. There are subtle consequences from this. Executing processes are effectively memory-mapped files that constantly rewrite themselves, with only the snapshots being written out. Snapshotting the virtual memory state of the system snapshots everything -- including the state of running processes. There's no need for a file system, just a means to map names to sets of pages, which is done by an ordinary process. After a crash, processes and their state are internally consistent, and continue running from their last snapshot. For those who are intrigued, there's a good introduction, written in 1979, by the system's designers available here: http://cap-lore.com/CapTheory/upenn/Gnosis/Gnosis.html http://cap-lore.com/CapTheory/upenn/Gnosis/Gnosis.html (It was GNOSIS before being renamed KeyKOS.) And a later document written in the 90s aimed at UNIX users making the case: http://cap-lore.com/CapTheory/upenn/NanoKernel/NanoKernel.html http://cap-lore.com/CapTheory/upenn/NanoKernel/NanoKernel.ht... Some work on capability systems continues, but it seems the lessons learned have largely been forgotten.

eru 4y ago
Ironically, Microsoft's Windows is one of the only big non-Unix operating systems out there. I say ironically, because people seldom bring up the Microsoft ecosystem as a beacon of adding to diversity.
- frankharv 4y ago
  Didn't Windows Network stack come from NetBSD? There were many BSD contributions to Windows.. BSD386 was a direct Unix derivative I would argue.
  - eru 4y ago
    Of course, Windows (and especially Windows NT) learned and borrowed from the Unix world. But it retains a distinct personality and lineage.
    - smegger001 4y ago
      Correct me if i am wrong but isn't the NT design heavily based off of (some would say a rip off of) VMS, Microsoft having poached much of DEC's OS dev team including chief architect David Cuttler.
      - seabrookmx 4y ago
        Yes, and DOS inherited things from older DEC operating systems like TOPS10 (which IIRC was the first occurrence of using /forwardslash options on the command line).
        skissane 4y ago
        Many are under the mistaken impression that DOS got forward slash as an option character from CP/M or from IBM. CP/M denoted options using square brackets, and IBM mainframe operating systems generally indicate options using parenthesises. (The usage of square brackets appears to be a modification of IBM's approach; I'm not sure why Gary Kildall made that change – before creating CP/M, he'd used IBM CP/CMS at the Naval Postgraduate School, which likely influenced both this option style, and also drive letters.) My own reconstruction of what I think happened (this was all before I was born, I'm just making some inferences based on what I know about the topic) – Microsoft was heavily influenced by DEC operating systems (Bill Gates and Paul Allen wrote the first version of Microsoft Basic on a PDP-10). Microsoft didn't like CP/M's native option syntax, so for their development tools for CP/M, they adopted a DEC-style option syntax instead. Since many ISVs used Microsoft's development tools, a lot of third party software on CP/M ended up using the same option syntax too. Tim Paterson at Seattle Computer Products was influenced a lot by Microsoft (even before he worked for them), so QDOS/86-DOS/PC-DOS/MS-DOS ended up with the DEC/Microsoft-style forward slash as an option character. When DOS 2.0 came around, Microsoft wanted to switch it to dash/minus, for better Unix/Xenix compatibility. In support of this, they added a CONFIG.SYS setting SWITCHCHAR= to let you choose between forward slash and dash/minus, and an API (INT 21,37) to get/set that config setting at runtime. However, it was decided that the backward compatibility cost of that change was too great, so they pulled the feature from the documentation (although it still existed in the code; in later DOS versions, they disabled the ability to change it to anything other than forward slash, but the undocumented API to get the setting was never removed.)
dhosek 4y ago
I think that a lot of interesting things were lost from the IBM and DEC operating systems. I spent a lot of time in VM/CMS and VAX/VMS (plus a little MVS/TSO) in the 80s and 90s and my Unix time was relatively limited for quite a while. I really liked Rexx (IBM’s scripting language which they brought into OS/2, but is now pretty much dead) and the way that command line options for VMS programs could be declared independently of the executable (plus its automatic allowance for abbreviations where you could abbreviate a command to its minimal unique prefix).
- josteink 4y ago
  > I really liked Rexx (IBM’s scripting language which they brought into OS/2, but is now pretty much dead) I’m not sure if it is the same, but back in my Amiga-days we had Arexx which I thought was an amazing tool to do tool-automation. To this day I haven’t seen anything quite like it. The closest is P to ably Windows and COM, but nobody likes that ;)
  - dhosek 4y ago
    Yes, the Amiga Rexx was based on IBM’s Rexx. I don’t know if they coded it to be compatible or licensed code from IBM.
pjmlp 4y ago
Enjoy the demo of Mesa/Cedar then, "Eric Bier Demonstrates Cedar" https://www.youtube.com/watch?v=z_dt7NG38V4 https://www.youtube.com/watch?v=z_dt7NG38V4 One for Oberon, https://www.youtube.com/watch?v=OJGnpmnXR5w https://www.youtube.com/watch?v=OJGnpmnXR5w IBM Redbooks are a source of information for IBM i and z https://www.redbooks.ibm.com/ https://www.redbooks.ibm.com/ And Burroughs is still sold as ClearPath MCP. https://public.support.unisys.com/search2/DocumentationSearch.aspx?ID=1207&pla=ps&nav=ps https://public.support.unisys.com/search2/DocumentationSearc...
mort96 4y ago
> you still can't trivially freeze a process, tweak a few values in its memory, and resume it as an integrated part of the operating system Can't you do this with gdb? Running `gdb -p <some pid>` pauses that process, you can inspect it, set breakpoints, change values in memory, etc, and then resume execution.
skissane 4y ago
> The debugger was always available, basically Because ITS had the debugger (DDT) as its shell. ITS wasn't the only OS for which this was true – the same was effectively true of CTSS, since in CTSS debugging was just a bunch of shell commands, not launching a separate "debugger". The same is true of IBM VM/CMS, for assembler-level debugging. (Source-level debugging is launching a separate program though.) One interesting feature of ITS – it had an API (called "valret" or "valretting") which an application could call to run a command in the OS shell/debugger. So basically, an application could actually control the debugger debugging it. I've never seen any other system with that feature, although it is possible to implement with GDB – allocate a buffer, put a "run this debugger command" request in it, pass it to a dummy function which just returns. Have a "processed" flag in the buffer – without a debugger, calling the dummy function will not set that flag, so the app knows no debugger is listening for commands. Now write a GDB Python script which sets a breakpoint on that function, when the breakpoint is hit, it reads the command out of the buffer, runs it, optionally writes any reply back in to it, sets the processed flag, then continues execution. The app can see the processed flag is set, so it knows the command was run, and can read any reply from the buffer too. MS-DOS COMMAND.COM did have a somewhat related feature – INT 0x2E. You could use that to tell COMMAND.COM to run a command. The difference from e.g. the C system() function, is it didn't spawn a child process COMMAND.COM to run the command, it told the parent COMMAND.COM to run it for you. (What many people today don't understand about MS-DOS, is it was actually a pseudo-multitasking operating system – it supported having multiple processes in memory at once, unlike many earlier operating systems such as CP/M which only supported having a single process in memory at a time – but unlike an actual multi-tasking OS, only the single foreground process could actually be running, all other processes would suspended – so you could have a child process, but you'd be suspended while it ran. An ancestor process could export an API to its descendant processes by installing an interrupt handler, which is exactly what COMMAND.COM did by installing a handler for INT 0x2E.)

by retrac 4y ago

eru 4y ago

Ironically, Microsoft's Windows is one of the only big non-Unix operating systems out there. I say ironically, because people seldom bring up the Microsoft ecosystem as a beacon of adding to diversity.

frankharv 4y ago
Didn't Windows Network stack come from NetBSD? There were many BSD contributions to Windows.. BSD386 was a direct Unix derivative I would argue.
- eru 4y ago
  Of course, Windows (and especially Windows NT) learned and borrowed from the Unix world. But it retains a distinct personality and lineage.
  - smegger001 4y ago
    Correct me if i am wrong but isn't the NT design heavily based off of (some would say a rip off of) VMS, Microsoft having poached much of DEC's OS dev team including chief architect David Cuttler.
    - seabrookmx 4y ago
      Yes, and DOS inherited things from older DEC operating systems like TOPS10 (which IIRC was the first occurrence of using /forwardslash options on the command line).
      - skissane 4y ago
        Many are under the mistaken impression that DOS got forward slash as an option character from CP/M or from IBM. CP/M denoted options using square brackets, and IBM mainframe operating systems generally indicate options using parenthesises. (The usage of square brackets appears to be a modification of IBM's approach; I'm not sure why Gary Kildall made that change – before creating CP/M, he'd used IBM CP/CMS at the Naval Postgraduate School, which likely influenced both this option style, and also drive letters.) My own reconstruction of what I think happened (this was all before I was born, I'm just making some inferences based on what I know about the topic) – Microsoft was heavily influenced by DEC operating systems (Bill Gates and Paul Allen wrote the first version of Microsoft Basic on a PDP-10). Microsoft didn't like CP/M's native option syntax, so for their development tools for CP/M, they adopted a DEC-style option syntax instead. Since many ISVs used Microsoft's development tools, a lot of third party software on CP/M ended up using the same option syntax too. Tim Paterson at Seattle Computer Products was influenced a lot by Microsoft (even before he worked for them), so QDOS/86-DOS/PC-DOS/MS-DOS ended up with the DEC/Microsoft-style forward slash as an option character. When DOS 2.0 came around, Microsoft wanted to switch it to dash/minus, for better Unix/Xenix compatibility. In support of this, they added a CONFIG.SYS setting SWITCHCHAR= to let you choose between forward slash and dash/minus, and an API (INT 21,37) to get/set that config setting at runtime. However, it was decided that the backward compatibility cost of that change was too great, so they pulled the feature from the documentation (although it still existed in the code; in later DOS versions, they disabled the ability to change it to anything other than forward slash, but the undocumented API to get the setting was never removed.)

dhosek 4y ago

I think that a lot of interesting things were lost from the IBM and DEC operating systems. I spent a lot of time in VM/CMS and VAX/VMS (plus a little MVS/TSO) in the 80s and 90s and my Unix time was relatively limited for quite a while. I really liked Rexx (IBM’s scripting language which they brought into OS/2, but is now pretty much dead) and the way that command line options for VMS programs could be declared independently of the executable (plus its automatic allowance for abbreviations where you could abbreviate a command to its minimal unique prefix).

josteink 4y ago
> I really liked Rexx (IBM’s scripting language which they brought into OS/2, but is now pretty much dead) I’m not sure if it is the same, but back in my Amiga-days we had Arexx which I thought was an amazing tool to do tool-automation. To this day I haven’t seen anything quite like it. The closest is P to ably Windows and COM, but nobody likes that ;)
- dhosek 4y ago
  Yes, the Amiga Rexx was based on IBM’s Rexx. I don’t know if they coded it to be compatible or licensed code from IBM.

pjmlp 4y ago

Enjoy the demo of Mesa/Cedar then, "Eric Bier Demonstrates Cedar" https://www.youtube.com/watch?v=z_dt7NG38V4 https://www.youtube.com/watch?v=z_dt7NG38V4 One for Oberon, https://www.youtube.com/watch?v=OJGnpmnXR5w https://www.youtube.com/watch?v=OJGnpmnXR5w IBM Redbooks are a source of information for IBM i and z https://www.redbooks.ibm.com/ https://www.redbooks.ibm.com/ And Burroughs is still sold as ClearPath MCP. https://public.support.unisys.com/search2/DocumentationSearch.aspx?ID=1207&pla=ps&nav=ps https://public.support.unisys.com/search2/DocumentationSearc...

mort96 4y ago

> you still can't trivially freeze a process, tweak a few values in its memory, and resume it as an integrated part of the operating system Can't you do this with gdb? Running `gdb -p <some pid>` pauses that process, you can inspect it, set breakpoints, change values in memory, etc, and then resume execution.

skissane 4y ago

> The debugger was always available, basically Because ITS had the debugger (DDT) as its shell. ITS wasn't the only OS for which this was true – the same was effectively true of CTSS, since in CTSS debugging was just a bunch of shell commands, not launching a separate "debugger". The same is true of IBM VM/CMS, for assembler-level debugging. (Source-level debugging is launching a separate program though.) One interesting feature of ITS – it had an API (called "valret" or "valretting") which an application could call to run a command in the OS shell/debugger. So basically, an application could actually control the debugger debugging it. I've never seen any other system with that feature, although it is possible to implement with GDB – allocate a buffer, put a "run this debugger command" request in it, pass it to a dummy function which just returns. Have a "processed" flag in the buffer – without a debugger, calling the dummy function will not set that flag, so the app knows no debugger is listening for commands. Now write a GDB Python script which sets a breakpoint on that function, when the breakpoint is hit, it reads the command out of the buffer, runs it, optionally writes any reply back in to it, sets the processed flag, then continues execution. The app can see the processed flag is set, so it knows the command was run, and can read any reply from the buffer too. MS-DOS COMMAND.COM did have a somewhat related feature – INT 0x2E. You could use that to tell COMMAND.COM to run a command. The difference from e.g. the C system() function, is it didn't spawn a child process COMMAND.COM to run the command, it told the parent COMMAND.COM to run it for you. (What many people today don't understand about MS-DOS, is it was actually a pseudo-multitasking operating system – it supported having multiple processes in memory at once, unlike many earlier operating systems such as CP/M which only supported having a single process in memory at a time – but unlike an actual multi-tasking OS, only the single foreground process could actually be running, all other processes would suspended – so you could have a child process, but you'd be suspended while it ran. An ancestor process could export an API to its descendant processes by installing an interrupt handler, which is exactly what COMMAND.COM did by installing a handler for INT 0x2E.)