jpayne%bbn-vax@sri-unix.UUCP (01/30/84)
From: Jonathan Payne <jpayne@bbn-vax> Uh, what is a virtual terminal?
nather@utastro.UUCP (Ed Nather) (02/01/84)
<>
From: Jonathan Payne <jpayne@bbn-vax>
Uh, what is a virtual terminal?
That's best described by an example. For instance, here's a virtual message:
--
Ed Nather
ihnp4!{ut-sally,kpno}!utastro!nathermather@uicsl.UUCP (02/03/84)
#R:sri-arpa:-1616200:uicsl:21300004:000:512
uicsl!mather Feb 2 13:21:00 1984
It's a terminal that can be set to virtually any mode.
It's a terminal that is wired via relocation pointers.
It's a terminal that has a 'paging' feature.
It's a terminal that isn't really there.
It's a terminal that you wish you had, but can't afford.
B.C.Mather
Le Maitre
uiucdcs!uicsl!mather
One man's bug is another man's feature.
- anonymous Un*x userrpw3@fortune.UUCP (02/03/84)
#R:sri-arpa:-1616200:fortune:26900021:000:917
fortune!rpw3 Feb 3 03:17:00 1984
A 'virtual terminal' is, depending on context, one or more of:
1. A remote login to another system;
2. A pseudo-terminal (/dev/ttypnn or PTYnn:);
3. A protocol;
4. An abstract object that a program speaks to as if it were
a physical device, but which another program supplies the
translation or interpretation for;
5. An abstract specification for an ideal (or real) terminal
(see also, "termcap"); a reference model.
For example, a window manager might present the view of a
specific virtual terminal, say a DEC VT-100, to each of the
processes running under it, while actually displaying the output
in various sized boxes on a physical ADM3 or an IBM PC.
To say "a presentation layer protocol (ISO/OSI level 6)" is probably closest.
Rob Warnock
UUCP: {sri-unix,amd70,hpda,harpo,ihnp4,allegra}!fortune!rpw3
DDD: (415)595-8444
USPS: Fortune Systems Corp, 101 Twin Dolphins Drive, Redwood City, CA 94065guy@rlgvax.UUCP (Guy Harris) (02/08/84)
Actually, bashing the innards of UUCP to make it run over a LAN isn't too
bad. We're running the 4.2BSD UUCP here, and it has support for UUCP over
a TCP/IP connection (it assumes the UNET TCP/IP implementation, though we
have a library that provides UNET-compatible subroutine calls under 4.2BSD);
we added a super-dumb protocol that assumes that the underlying network
protocol (TCP, in this case) does all the error handling and flow control.
It gets about 150KB over the Ethernet, which is about the same or higher
than the bandwidth FTP gets; running a vanilla UUCP over a LAN would be
quite a bit less efficient, as the "g" link-level protocol's overhead would
be unnecessarily added to the other transmission overheads.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guyajs@hpfcla.UUCP (02/11/84)
Here's another example of virtual terminal... Let's say you have a set
of machines hooked up over a LAN (Local Area Network, maybe Ethernet
based). Suppose you also have an existing application package, say,
uucp, which knows all about RS-232 lines but nothing about LAN. A lot
of higher-level utilities ride on top of uucp. You'd like to send
email, news, etc. over the LAN (it's faster, and maybe it's the only
available route). You don't want to mess with the innards of uucp
(ugh). What do you do?
In this case, virtual terminal comes to the rescue as support for
special files that act like RS-232 ports (say, /dev/culnet) but actually
give access to the LAN, hiding the details. Presto, you can uucico at
jillions of baud, without knowing there's any difference between
/dev/culnet and any hardwired line.
Alan Silverstein, Hewlett-Packard Fort Collins Systems Division, Colorado
{ihnp4 | hplabs}!hpfcla!ajs, 303-226-3800 x3053, N 40 31'31" W 105 00'43"dce@ihnss.UUCP (Dan Easley) (11/02/84)
Wanted: A driver for UN*X 4.0 which will permit multiple processes to each have a virtual terminal in one window of a graphics terminal. I basically need a BLIT like facility for a BLIT like terminal, except that I can't download code into the terminal. I am already aware of Blewett's "Hmmm" and Veach's "windows", both of which are processes using multiple pipes. I'm also aware of Horton's "window" (which requires "select" and "pty" from 4.2BSD), and UN*X 5.2's "xt" and "sty" driver's (but I'm running 4.0). A UN*X 4.0 facility similar to select (a multiplexor which hangs on *multiple* files) or pty (pseudo tty) would also by helpful. Thanks! Dan Easley ihnss!dce