Re: [TUHS] Systematic approach to command-line interfaces

[Paul Winalski <paul.winalski@gmail.com>]

On 8/3/21, Andrew Warkentin <andreww591@gmail.com> wrote:
>
> Up until now I was just planning on following the traditional
> threading model of associating most state with processes with only
> execution state being per-thread in the OS I'm working on, but now I'm
> thinking I should reduce the state associated with a process to just
> the PID, PPID, PGID, containing cgroup, command line, and list of
> threads. All other state would be contained in various types of
> context objects that are not tied to a particular process or thread
> (other than being destroyed when no more threads are associated with
> them).

For what it's worth, this is the process model that Windows NT has.

This thread has discussed two very different ways to do command line
processing:  the TOPS-20 model, where the program image for the
command is activated immediately and then calls back to the OS to
process the command line elements, and the UNIX model, where the first
element of the command line is a path (full or partial) to the program
image for the command, and it's entirely up to that image to process
the command line elements as it sees fit.

VMS takes a third approach.  The VAX had four, hierarchical execution
modes:  user, supervisor, exec, and kernel, in increasing order of
privilege.  The VAX had "change mode" instructions (CHMU, CHMS, CHME,
CHMK) that ran the current process's change-mode interrupt handler to
process the request.  Applications and programs to process commands
ran in user mode.  The DCL command interpreter (VMS's equivalent of
the UNIX shell) ran in supervisor mode.  Exec mode was reserved for
record management services (RMS), VMS's equivalent of the file system
code in UNIX.  Kernel mode (the only mode where privileged
instructions can be executed) was, of course, for the kernel.  One
oddity of VMS is that each process had the supervisor, exec, and
kernel code and data mapped to its address space.

Commands in VMS are described using a meta-language that is compiled
into a set of data tables that the command line interpreter (CLI,
running in supervisor mode) uses to determine which program image
needs to be activated to execute the command.  The CLI also does a
full parse of the command line.  It then calls the kernel's image
activator to map the appropriate program image and switches to user
mode to start it running.  There is a runtime library of routines to
retrieve the various options and parameters from the command line (the
routines in this library do CHMS calls to achieve this).

So on VMS we have a situation where the command interpreter (shell) is
part of every process.  Processes are created by the "create process"
OS library routine, sys$creprc, which is a wrapper around the
appropriate CHMK instruction.  Unlike fork() on UNIX, the new process
inherits very little state from its parent.  Most significantly it
inherits neither address space nor open file context.  VMS process
creation is also notoriously expensive compared to fork() on UNIX.

-Paul W.