Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site uiucuxc
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!uiucuxc!hamilton
From: hamilton@uiucuxc.CSO.UIUC.EDU
Newsgroups: net.micro.amiga
Subject: Re: Review of MyCLI.c (Author Mike Schw
Message-ID: <148600035@uiucuxc>
Date: Mon, 20-Jan-86 01:29:00 EST
Article-I.D.: uiucuxc.148600035
Posted: Mon Jan 20 01:29:00 1986
Date-Received: Wed, 22-Jan-86 05:43:42 EST
References: <3006@vax4.fluke.UUCP>
Lines: 92
Nf-ID: #R:vax4.fluke.UUCP:3006:uiucuxc:148600035:000:4360
Nf-From: uiucuxc.CSO.UIUC.EDU!hamilton    Jan 20 00:29:00 1986


>From my work on MyCLI, I have a pretty good idea that the Amiga makes an
>incredible terminal for UNIX!!  I think it would be VERY TRIVIAL to create
>a version of unix that interfaced to the Amiga and allowed Multiple 
>signons in multiple windows on one Amiga.
>I think the trivial change would
>be modifying the "output character" (lowest level) routine that is called
>by every unix program (via printf, puts, etc.) to output a window identifier
>prefix before each byte output (a number identifying which window the
>output goes to).  The Amiga can easily direct the character to the appropriate
>window...  

    first, i want to thank mike for mycli; there's a lot of good stuff
in there, and at the very least, he has saved me a lot of trial and error
research.
    regarding the quote above, there's a public domain program that should
take care of most of the Unix side of the job.  i'm enclosing the
README from the wms distribution.

	wayne hamilton
	U of Il and US Army Corps of Engineers CERL
UUCP:	{ihnp4,pur-ee,convex}!uiucdcs!uiucuxc!hamilton
ARPA:	hamilton@uiucuxc.cso.uiuc.edu
CSNET:	hamilton%uiucuxc@uiuc.csnet
USMail:	Box 476, Urbana, IL 61801
Phone:	(217)333-8703

<			WINDOW MANAGEMENT SYSTEM
<
<A window management system for 4.2bsd systems is being released by George 
<Nelan at Arizona State University.  The system, WMS, is in the public domain 
<and consists of :
<- MSH, an executable meta-shell manager which resides on the host, manages
<sub-shells (csh or user) via ptys, and coordinates communications with an 
<external window manager by multiplexing standard I/O;
<- WTY, a host-resident executable window manager built upon MSH, utilizing the 
<TERMCAP database so that most programs can run in windows (vi,..);
<- TOOLS, a set of code fragments to assist the do-it-yourself types in
<developing their own [remote] window managers (PC,..) for linkage to MSH;
<- DOCUMENTATION, a complete set of user manuals in the form of three 'man' 
<entries; and last, but not least,
<- SOURCE CODE.
<
<A brief description of WTY follows:
<WTY emulates a virtual windowing terminal on a variety of devices (vt100,..).
<The underlying actual device must support controllable scrolling regions and
<cursor motion as described by a [user-defined] TERMCAP entry. Windows are 
<defined as multiplexed scrolling regions; all windows span the width of the 
<display.  Each window is truly scrollable (without redraws) with all visible 
<windows the same size.  WTY multiplexes sub-shell output into windows in a 
<way that allows apparent concurrency.  A 'select current input window' command 
<may be used to direct user input to any visible window.  Other commands allow 
<window creation/deletion, opening/folding (making visible/invisible), 
<labeling (windows are not bordered since context usually provides sufficient 
<implicit discrimination clues - labels explicitly delimit borders), and 
<buffer manipulation: create/delete (I/O recording), open/fold (enable/disable 
<recording), and read selection (take a buffer as user input).  Window size 
<information is communicated to sub-shells by a wty-generated "setenv TERM <X>" 
<message, where <X> identifies a virtual terminal related to the window size.  
<A resize command allows retransmission of this message at any time.  A 'nice' 
<option on all commands which affect window size allows quiet dynamic
<manipulation of windows (no automatic "setenv" messages are generated).  A
<help command  provides a summary and the command character prefix may be user-
<defined.
<
<The system has been operational since June 1985 and seems to be fairly robust 
<and relatively efficient.  We will provide a copy of the system in 1600 BPI 
<TAR format if you send us:
<
<- A mag tape (the system release is ~ 256KB).
<- Return postage or a check payable for same made out to:
<	"A.S.U. Engineering Computer Center"
<  Or indicate shipping collect.
<  Shipping will be via UPS unless you specify otherwise.
<
<Upon special request, a shar version is available via UUCP.  As this file is
<123KB long (~20 min @ 1200B), we prefer tape transfers.
<
<Contact:
<
<	George Nelan
<	Engineering Research Center (ERC 207)
<	Arizona State University
<	Tempe, Arizona, 85287
<	(602)-965-2791
<
<	UUCP:	
<	...{ucbvax,ihnp4}!arizona!asuvax!nelan
<	...ihnp4!noao!terak!asuvax!nelan
<
<	CSNET:	
<	nelan@asu