Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Multiscreen on Unix
Message-ID: <20551@sun.uucp>
Date: Sun, 7-Jun-87 04:29:12 EDT
Article-I.D.: sun.20551
Posted: Sun Jun  7 04:29:12 1987
Date-Received: Sun, 7-Jun-87 20:04:32 EDT
References: <910@minnow.UUCP>
Sender: news@sun.uucp
Lines: 98

>     I would like to have multiple screens on Unix the way I do on
> SCO Xenix and Microport Unix.  

The only way to do multiple screens "on UNIX", rather than on a
particular UNIX machine or set of UNIX machines, is to assume that
all you have available is a dumb terminal.  There's a fair bit of
work involved in this.

> 1).    Has anyone written something do this?

Various people have done this; Mark Horton wrote a window system
whose source can be found in the System V, Release 3.0 source
distribution in the directory "/usr/src/lib/libcurses/demo/window".
(Various games, including what appears to be a version of the Space
Invaders game supplied with 4.1BSD, can also be found in the "demo"
directory.)  I think there may have been such a window system
supplied with the 4.3BSD alpha tape, or something like that; I don't
see it in any obvious place in the 4.3BSD distribution.

> 2).    Does anyone have any ideas on how to approach doing this?

If a program is writing to screen 1, while screen 2 is the
screen currently being displayed, some window manager must keep track
of the "virtual" screen 1.  This either means that:

	1) the window manager must be able to recognize all the
	   various control sequences that can be sent to any of the
	   terminals it supports - it could do a lot of this by
	   reading the "termcap" or "terminfo" description for that
	   terminal (idea courtesy of Dave Rosenthal's "psterm"
	   terminal emulator for NeWS), but this would require that
	   no program use any sequence other than the ones in the
	   description (which may very well be the case)

or

	2) the window manager will have to emulate a virtual
	   terminal of some sort, accepting sequences for that
	   virtual terminal as input and updating the physical
	   display using e.g. "curses".  (Mark Horton's window
	   system works this way.)

Both of these strategies are best done using some sort of pseudo-tty
mechanism, which is not supplied with vanilla System V, but appears
in 4.[23]BSD and a lot of other UNIX systems (including lots of
System V-compatible systems).  (There may be ways of doing this with
pipes, but there are some problems with that - see below.)

Also, the window manager would have to intercept input from the
terminal, in order to know when to switch windows/screens, unless you
added a new "switch windows" character to the tty driver and arranged
to have some event, such as a signal, delivered to the window manager
when this character was typed, without affecting any programs running
in the window.

If this trick were used, the window manager would somehow have to
"freeze" programs running in inactive windows/screens, to prevent
them from reading from the keyboard, or would have to use some
mechanism such as the "sxt" devices used by shell layers to multiplex
screens.  ("sxt" devices would also provide the "switch" character
for switching "shell layers", which could be used to switch between
windows/screens instead - alas, "sxt"s have NO mechanism for
multiplexing output, so you'd have to have something like pseudo-ttys
for this.)

If you have pseudo-terminals, you can use them for input multiplexing
and capturing the screen-switching commands as well.  If not, you
might be able to cobble something together with "sxt"s and pipes,
although some programs might get confused if their standard input
were an "sxt" and their standard output and error were pipes - some
would think they were at a terminal and behave correctly, some
wouldn't and wouldn't act correctly (e.g., not line-buffering their
output), and some might work half-correctly.

Note that pipes could not substitute for pseudo-ttys on the *input*
side, unless you're willing to sacrifice a lot of things; pipes don't
do erase/kill processing, and don't pass "ioctl"s through, so the
window manager would either always have to do the erase/kill
processing, never do it, or be told via a special window-manager
command whether to do it or not.  Would you rather not be able to
correct typing errors, not be able to run screen editors (or other
non-cooked-mode programs) inside a window, or be obliged to switch
modes when entering and leaving screen editors?  Some programs that
do "isatty(0)" to see if they're being run from a terminal (i.e.,
interactively) would get confused as well.

A way of getting around this would be some way of running full-screen
programs from the window manager, rather than from a shell in a
window.  The window manager would make the current screen no longer
be the active screen, without making any other screen the active
screen, and would also hand control of the keyboard over to the
program in question.  When that program exited, it would reclaim
control of the keyboard and would make the current screen the active
screen again.  Of course, this means that when you're running a
full-screen program, you don't have multiple screens or windows....
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com