/****************************************************************************\
 * Copyright 1985 by George Nelan, Arizona State University.                *
 * All rights reserved.  Permission to use, modify, and copy these programs *
 * and documentation is granted, provided that the copy is not sold and     *
 * that this copyright and permission notice appear on all copies.          *
\****************************************************************************/

------------------------------------------------------------------------------
General notes & philosophy...
------------------------------------------------------------------------------


------------------------------------------------------------------------------
The source codes reference include files which they think are in their own 
local directory.  These files are symbolically linked to where they are 
relative to the distribution directory structure.  This needs to be considered 
if the structure is disturbed (a relink may be necessary - see the 'relink'
script in this directory).


------------------------------------------------------------------------------
For wty, the requirement that terminals possess a controllable scrolling
region can be extended to cover tvi-925 and other types.  This would 
require either a unique format for the 'cs' cap (of the actual device),
or perhaps more appropriately, a new cap for wty only (so that other programs
do not get confused by the non-standard 'cs' format).
This would allow wty to distinguish between various methods of 'cs'.


------------------------------------------------------------------------------
The initial version of wty used the *curses* library and was found to be
unsatisfactory for these reasons:

o  Programs which do cursor motion usually optimize such motion themselves, 
possibly via curses itself.  No redundancy in this area was desired.

o  Curses' idea of scrolling windows means to redraw a portion of the screen.
For arbitrary size windows on a vanilla terminal,  there is no other way.
Simply by restricting window dimensions however, it is possible to efficiently 
implement truly scrollable windows via multiplexing of the scrolling region.

Hence the lower level termcap library was used instead.  However, not using 
curses makes it more difficult to implement internal buffering & window 
refresh.  It would be nice to be able to scroll and refresh internal buffers.


------------------------------------------------------------------------------
The method of communicating the current window size to a sub-shell needs to
be thought about more carefully.  The "setenv" message is the simplest way,
but leaves much to be desired.


------------------------------------------------------------------------------
Msh has a hook in it to keep roots from using it.  When our own local root
tested it, we found strange things happening to various sockets.  Since I
am not the root here, it is difficult for me to validate possible solutions.
I believe such problems have been resolved, but I cannot be sure.  Therefore,
remove this hook at your own risk.  (The hook is in init_msh(), the problem
seemed to be in do_QX() and/or do_DS()).


------------------------------------------------------------------------------
Signal handling is minimal.  Some thought needs to be done about putting msh
to sleep when IO inactivity exceeds some threshold, waking up of course on
resumed IO activity.


------------------------------------------------------------------------------
In both wty & msh, input command procedures are intentionally split into
duals so that one procedure manages input parameters (if any), checking
syntax and semantics; and the other manages the function itself.  This method
introduces redundancy in some cases; but for the sake of consistency, all
future expansions should follow the same style.  At least this allows the
second procedure to be used independently of the first.


------------------------------------------------------------------------------
The following graph illustrates the primary flow of control for msh:

main:
    init_msh
    loop
	slave_driver (for next slave i)
	    master_driver
		get_master, read tty
		exec_cmd | put_slave, write pty
	    get_slave(i), read pty(i)
	    put_master 
    |__


------------------------------------------------------------------------------
The following graph illustrates the primary flow of control for wty/msh:

main:
    init_msh
    init_wty
    loop
	screen_driver
	    get_port (if pq empty)  
		slave_driver (for next slave i)
		    master_driver
			get_master (if mq empty)
			    keyboard_driver
				get_keyboard, read tty
				put_port
			put_slave, write pty
		    get_slave(i), read pty(i)
		    put_master 
	    put_screen(i), write tty
    |__


