mikec@reed.UUCP (Michael Cooper) (04/28/85)
I posted an article a couple of weeks ago on this subject, but never even
heard a whisper on it. The question was: What are Virtual Terminals? I
have seen references to them several times. Recently in tset.c. It seems
to be some kernal code for mapping terminal capibilities. Would someone
please enlighten me? I'm rather curious.
--
Michael Cooper
______________________________________________________________________________
{decvax, ucbvax, purdue, uw-beaver, masscomp, cbosg, aat, sdcrdcf,
mit-ems, psu-cs, uoregon, orstcs, ihnp4, uf-cgrl, ssc-vax}!tektronix
\
+--!reed!mikec
{teneron, ogcvax, muddcs, cadic, oresoft, grpwre, /
harvard, psu-cs, omen, isonvax, nsc-pdc}-------------+ART@acc.ARPA (Art Berggreen) (04/30/85)
Regarding the query about "Virtual Terminals":
I have seen the term "Virtual Terminal" used in a couple of different
ways. The first usage is often also called "Psuedo Terminal" or
"Remote Terminal" and refers to termination of computer network
connections in such a way as to emulate a locally attached physical
terminal. There are several protocols which define the content of
the network traffic involved in the terminal connection. Examples
include CCITT X.29, DoDs TELNET and DECs new LAT protocol (there are
certainly many more).
The second usage of the term is in defining a conceptual, generic
terminal (therefore Virtual) which can be used as a standard template
for heterogeneous environments. The behavior and data of a real
terminal is mapped into the (hopefully) equivalent virtual terminal
for use by other parts of the system. DoDs TELNET protocol is based
on the concept of a Virtual Terminal definition. Because of the
diversity of terminals (TTYs --> IBM 3270s) comprehensive Virtual
terminal definitions and support functions can get very complicated.
"Art Berggreen"<Art@ACC.ARPA>
------root%bostonu.csnet@csnet-relay.arpa (BostonU SysMgr) (05/01/85)
There's more than one definition (term is 'overloaded') but from a 4.2 context here's a functional definition: The UCB program 'script' works essentially by starting a shell up to a psuedo-tty for you and going into a simple figure-8 loop taking the typein from your terminal and sending it to the pty, taking the typeout from the pty and sending it to your tty (copying everything into a dribble file.) Now, say you 'lied' to the pty side and claimed to always be a VT52 or some such no matter what was on the other end. Now, get the termcap for the VT52 and the user's actual terminal and just map the incoming (pty) side escape sequences to the outgoing (your) side. Of course, you say, why bother. Now assume your terminal just cannot be easily described by a termcap definition but really requires a full blown, custom program to control (maybe you have font capability and need to do some fancy stuff to take advantage of it so you want to translate under-scoring to italics etc, which requires calculating new x/y position dependant on current font, not do-able directly thru termcap.) A VTS might solve your problem. The big split between VTS's and Termcap was that a VTS assumes the remote tty is very hard to control and has significant peculiarities that require a custom, smart program to control (eg. CRTSTY on ITS). Termcap assumes that terminals are remarkably similar and most common functions can map to a few generic operations. Both approaches are correct under different circumstances. Termcap is much easier to maintain, VTS's can be much more powerful and still not force software to 'hard code' terminal knowledge in general (maybe, but you have to be real careful about your 'generic' terminal!) Of course, then there are certain manufacturers who solve the problem by filling all their code with the constants 24, 80 and 'ESC-[-H' and just tell you to buy their terminals sigh ;-) -Barry Shein, Boston University
jsdy@hadron.UUCP (Joseph S. D. Yao) (05/14/85)
> ... What are Virtual Terminals?
Generally, the concept of "virtual terminals" is that you have some
things somewhere that aren't terminals, but you can pretend that they
are by logging in on them and using them as your process controlling
terminals. Real terminals are, e.g., VT100's hooked up to a DHDM
line hooked up to a UNIBUS. A virtual terminal might lead through a
VT driver into a single network port shared with dozens of other VT's;
or into a socket that is talking to a process that wants to look like
a user logging in (and that process could be on the same machine or
on another); or into a window on a TTY 6520 DMD (rev 1.1!) (blit, jerq,
whatever); or into virtually anything that wants to pretend it is a
real, live, ASCII(or whatever)-spitting terminal device on a terminal
line ... but isn't.
Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}