Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1a 12/4/83; site rlgvax.UUCP Path: utzoo!watmath!clyde!floyd!harpo!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: V.2 Job Control Message-ID: <1657@rlgvax.UUCP> Date: Sat, 4-Feb-84 18:22:13 EST Article-I.D.: rlgvax.1657 Posted: Sat Feb 4 18:22:13 1984 Date-Received: Thu, 9-Feb-84 06:51:07 EST References: <794@omsvax.UUCP> <440@abnjh.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 42 > Within the limitations of the terminal hardware, there is a lot of > commonality between the functions needed to support a Blit and the code to > provide Job Control. In the case of the Blit, a lot of the code > actually resides in the Blit, in the case of the "dumb" terminal using > Job Control, the code resides in the kernel, but there is no excuse > for the user having to see the difference, as long as s/he sticks to a > prescribed subset of functions. The main difference between the Blit multi-layer support and the S5R2 "job control" multi-layer support is that the Blit is an intelligent terminal with a lot of local memory and software specifically designed to support multiple overlapping windows. A "virtual terminal" has several sorts of state information; the ioctl modes of the terminal port, the current contents of the virtual screen of that virtual terminal, and the internal state of that terminal. An example of the latter might be the the state of a VT100's line-wrap option (whether an attempt to put a character in column 81 causes the cursor to move to the beginning of the next line or not), of its keypad (whether it transmits numbers or escape sequences), or of its current character set. The S5R2 "job control" mechanism does preserve the ioctl modes, but it does *not* preserve the internal state of the terminal. To do this, all characters output to the terminal would have to pass through a routine which knew *all* the character sequences that affected the terminal's internal state and would have to interpret them; furthermore, it would have to know how to save and restore that state. It would also have to preserve the screen's contents, so that when switching from one virtual terminal to another the screen would be properly painted with the contents of the new virtual terminal's screen. Another way to do this would be to provide a fake terminal type which is designed for multi-windowing, and have the programs write character sequences for this pseudo-terminal which would be interpreted by a program which knew how to simulate those functions on the actual terminal. All this is difficult at best, and impossible at worst (there may be terminals which simply can't support this). The Blit is different, because its software was specifically designed to make all this possible, so it's not fair to assume that what's available transparently to processes talking to a Blit can be made available to processes talking to arbitrary terminals. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy