Difference between revisions of "TENEX"

From Computer History Wiki
Jump to: navigation, search
(An OK start)
 
m (link command processor)
Line 16: Line 16:
 
It was written by a small team at BBN for a [[KA10]] modified to add the hardware for [[virtual memory|paging]] (much as the MIT AI Lab added hardware to their KA10 for the same purpose). (The lack of a DEC [[mainframe]] with paging at the time was the primary driver for the creation of TENEX.) It was later adapted to run on the paging hardware supplied by DEC with the [[KI10]] (although not as efficiently).
 
It was written by a small team at BBN for a [[KA10]] modified to add the hardware for [[virtual memory|paging]] (much as the MIT AI Lab added hardware to their KA10 for the same purpose). (The lack of a DEC [[mainframe]] with paging at the time was the primary driver for the creation of TENEX.) It was later adapted to run on the paging hardware supplied by DEC with the [[KI10]] (although not as efficiently).
  
Each user can have a hierarchy of [[process]]es, starting with the 'EXEC', the command interpreter (the collection being referred to as a 'job'); a 'superior' process has complete control over an 'inferior'. Processes may share memory with each other, and also map [[file]]s into their [[address space]]; memory shared between processes can be either readable, writeable, or 'copy on write'. [[Interrupt]]s may arrive from either the controlling keyboard of the job, or from another process in the job; [[trap]]s can be caused by the process' operation (e.g. illegal memory references).
+
Each user can have a hierarchy of [[process]]es, starting with the 'EXEC', the [[command processor]] (the collection being referred to as a 'job'); a 'superior' process has complete control over an 'inferior'. Processes may share memory with each other, and also map [[file]]s into their [[address space]]; memory shared between processes can be either readable, writeable, or 'copy on write'. [[Interrupt]]s may arrive from either the controlling keyboard of the job, or from another process in the job; [[trap]]s can be caused by the process' operation (e.g. illegal memory references).
  
 
It provided the by-then-usual hierarchical file system, with protection (list, read, write, append, execute) to prevent one user from damaging another's files. File names included version numbers, which were automatically incremented when a file is written.
 
It provided the by-then-usual hierarchical file system, with protection (list, read, write, append, execute) to prevent one user from damaging another's files. File names included version numbers, which were automatically incremented when a file is written.
  
 
The system included three different debuggers, all versions of [[DDT]]. The first operated on the OS itself, when the OS was not running; it could be used to debug any part of the OS. The second wass a close variant; it also operated on the OS, but with the OS running. The third was used to debug user processes.
 
The system included three different debuggers, all versions of [[DDT]]. The first operated on the OS itself, when the OS was not running; it could be used to debug any part of the OS. The second wass a close variant; it also operated on the OS, but with the OS running. The third was used to debug user processes.

Revision as of 21:42, 5 October 2017


TENEX
Type: Multi-tasking, multi-user, virtual memory
Creator: BBN
Architecture: PDP-10
Date Released: June, 1970


TENEX was an early operating system for the PDP-10 line of computers; it was the ancestor of the later DEC-supplied operating system for the DECSYSTEM-20, TOPS-20.

The TENEX paging box for the KA10

It was written by a small team at BBN for a KA10 modified to add the hardware for paging (much as the MIT AI Lab added hardware to their KA10 for the same purpose). (The lack of a DEC mainframe with paging at the time was the primary driver for the creation of TENEX.) It was later adapted to run on the paging hardware supplied by DEC with the KI10 (although not as efficiently).

Each user can have a hierarchy of processes, starting with the 'EXEC', the command processor (the collection being referred to as a 'job'); a 'superior' process has complete control over an 'inferior'. Processes may share memory with each other, and also map files into their address space; memory shared between processes can be either readable, writeable, or 'copy on write'. Interrupts may arrive from either the controlling keyboard of the job, or from another process in the job; traps can be caused by the process' operation (e.g. illegal memory references).

It provided the by-then-usual hierarchical file system, with protection (list, read, write, append, execute) to prevent one user from damaging another's files. File names included version numbers, which were automatically incremented when a file is written.

The system included three different debuggers, all versions of DDT. The first operated on the OS itself, when the OS was not running; it could be used to debug any part of the OS. The second wass a close variant; it also operated on the OS, but with the OS running. The third was used to debug user processes.