1/11/84
  New map file allocation scheme.  Requires these changes:
    corshufl - X must have task address on call to getmap
             - all versions call getmap in "dupum"
    maphandlers - The routines "getmap" and "fremap" are now
                - in the kernal.
                - The routine "swtchu" must call "chkmap"
                - after resetting the stack pointer to
                - allocate a map file slot for the task.

04/06/84
  Sorted free list
  Improved mount protection
  XON/XOFF drivers in tty, spr

05/21/84
  Closing files 0..2 -> No associated terminal
  'cdata' will not allocate pages which cross 64K boundary
  Bug in 'Init' of allocating clists which crosses page boundary

06/05/84
  Changed 'ttyget' to use a buffer on the system stack instead
  of the common buffer 'tgtbuf'.  This caused problems with the
  GIMIX IOP system since ttyget functions were long and potentially
  interruptable.

02/06/85
  The routine which flushes buffers assigned to a block device
  was using 'romspr' for debug/trace purposes!  This caused the
  Pennywise system to fail since this byte actually contains
  system configuration information.

*** Release of X.11 kernal ***

03/22/85
  The code for detecting file descriptors 0..2 closed was incorrect.
  It was only checking 0..1.

04/01/85
  Changed "ttycls" (TTY close) to not call "flusho" if the port is
  not actually open.  Also, "flusho" was changed to not ask the
  question "is there CTS" because this cannot be performed reliably
  on all devices.

07/15/85
  Changed "exec" to always return "Not a Binary File" for any file
  which cannot be executed (e.g. a directory or device).  This means
  that programs such as the shell need to do a status on a file
  which gets this error from exec to determine if the reason for
  the error is the type of file [directory, etc] or its contents
  [a script as opposed to a binary image].

  The "load file" function in "exec" is now more robust.  Previously,
  any program which loaded data at an address of $F000 or higher
  has the possibility of crashing the system.  This is because the
  page at that address is used to hold the image of the exec parameters
  until the load is finished.  After the program is loaded, the
  parameters are moved to the top of the page.  If data was loaded
  into this page, pointers within the page are destroyed and the
  code goes banannas.
