Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!ames!oliveb!sun!gorodish!guy
From: guy%gorodish@Sun.COM (Guy Harris)
Newsgroups: comp.unix.questions
Subject: Re: Multiscreen on Unix
Message-ID: <21611@sun.uucp>
Date: Fri, 19-Jun-87 17:37:28 EDT
Article-I.D.: sun.21611
Posted: Fri Jun 19 17:37:28 1987
Date-Received: Mon, 22-Jun-87 04:13:46 EDT
References: <910@minnow.UUCP> <5942@brl-smoke.ARPA> <103@rb442.UUCP> <699@mrstve.UUCP>
Sender: news@sun.uucp
Lines: 42

> I didn't mean to emulate the entire curses library

Please reread what I said.  I never said you had to emulate the
entire curses library, just that you'd have to do enough of the same
thing that you're talking about putting LOTS of stuff into the
kernel.

> -- I just want to keep track of what is on 1 or more virtual screens (via
> an array/structure indicating size/location/etc).  On receipt of (say) a
> certain escape sequence, the appropriate module of the terminal driver
> would redraw the physical screen so it looked like the requested virtual
> screen.

OK, so how is it going to "keep track" of what's on the screen?  It
can't just blindly remember everything sent to the screen, unless it
remembers everything you sent since you first started talking to that
terminal, or until you last sent the terminal something that *this
module* recognized as somehow resetting the state of the terminal.
Frankly, the notion of redrawing the screen by retransmitting
everything sent to it since the screen was last cleared doesn't
appeal to me somehow; the fact that it's generally transmitted at no
better than 19.2KB, and could thus take a LONG time to redraw, may
have something to do with it.  (We won't even discuss the memory
required to hold this information.)

> The terminal driver shouldn't have to care about the *type* of the
> terminal at all -- it just passes whatever terminal control sequences
> it receives right on thru (thru to the structure (a queue, maybe), anyhow,
> which would later, when requested, just dump to the terminal).

See above.  Without large amounts of memory on the machine, and large
amounts of patience on the part of the user, this isn't going to work
very well at all.

You can do this sort of thing on PCs because their displays tend to
be memory-mapped, and the kernel could just stash the entire screen
image away somewhere and restore another one from its stored copy;
this takes a bounded amount of memory.  Doing this on arbitrary
terminals just won't fly.
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com