std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/07/86)
From: pyramid!utzoo!henry@sally.utexas.edu (Henry Spencer)
Date: Sat, 4 Oct 86 03:03:30 PDT
After some activity back when the Unix standard was with /usr/group, I've
"gone dormant" on standardization work through lack of time. I haven't
even seen most of the P1003 stuff. However, I understand that there is
a proposal to incorporate Berklix-like "job control" into P1003. Given
the interest in getting some new topics into mod.std.unix, I'm submitting
the following. It's a slightly touched-up version of a paper Ian Darwin
and I submitted to the /usr/group standards effort, arguing strongly that
neither 4BSD "job control" nor SysV "shell layers" should be incorporated
into a standard. Since I haven't seen the detailed P1003 proposal, it's
possible that some of this is out of date, but on the whole I think it's
of interest nonetheless.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,decvax,pyramid}!utzoo!henry
[ Perhaps whoever has the original online copy of the current P1003
proposal could submit it? That would probably be worthwhile even if
it had to be broken into several articles for space reasons. -mod ]
Comments on Terminal I/O, Specifically `Job Control'
Henry Spencer
University of Toronto
utzoo!henry
Ian Darwin
University of Toronto
utcsstat!ian
`Job Control', What It's Really About
There is no longer any argument that it is desirable to permit orderly
user interaction with multiple processes. Unfortunately, a whole generation
of Unix users has had their view of this concept warped by the dreadful way it
was implemented by Berkeley. And AT&T, in its recent attempt to address the
problem, has taken the easy way out instead of doing it right.
The basic concept involved here is multiplexing, not `job control' or
process suspension. The ideal is something like the environment on the Bell
Labs Blit, where multiple processes run simultaneously in multiple windows,
and the user can switch his attention and his interaction from one to another
at will. There is a popular misconception that doing this *requires* a Blit
or a similar highly-intelligent terminal; this is simply not true.
Window-based multiplexed interaction is harder to do when the terminal is
dumb, but even the Blit is not actually writing things into several windows
*simultaneously*: it just looks that way because of the high-speed multiplex-
ing involved. There is no intrinsic reason why this multiplexing cannot be
done at the other end of the communications line when the terminal is incapa-
ble of doing it.
The multiplexing can be done in the kernel (albeit at considerable cost
in added kernel complexity) or in a user process (given suitable interprocess
communication). In either case, the fundamental structure is quite simple: a
central `manager' coordinates terminal i/o to and from `client' processes,
each of which has total control of its own "virtual terminal". The manager's
job is simulating multiple virtual terminals on a single real terminal, by
routing input to the appropriate process and placing output in the appropriate
area of the screen.
- 2 -
The basic characteristics of such a multiplexing system are that each
process has what looks (to it) like a private terminal, and that all i/o to
and from the user is centrally supervised. This is precisely analogous to
file i/o under Unix: simultaneous independent activity by multiple processes,
coordinated by a central manager which multiplexes physical resources so as to
prevent interference. The benefits are similar: individual processes neither
know nor care about the multiplexing, and useful high-level abstractions can
be implemented in one central place.
Job Control and Layers: Half-Baked Approaches
The existing schemes, Berkeley `job control' and AT&T `layers', unfor-
tunately are clumsy and incomplete attempts at implementing multiplexed
interaction. Neither one makes any provision for simultaneous on-screen
activities by more than one process, except for the `cop-out' of permitting
multiple processes to intermix their output at random. But there are deeper
problems.
Both schemes require that *every* *program* which is going to participate
in multiplexed interaction must contain code to allow for this possibility!
User programs must be prepared to redraw the screen on request, with the
requests coming from the kernel in the Berkeley scheme and from the user in
the System V.2 scheme. This is an abomination.
Not only does this demand specialized code in every user program, but it
entirely denies multiplexed interaction to the bulk of Unix programs. The
concept of `redraw the screen' is meaningful only for interactive programs
with full-screen interfaces. The result of, say, an *egrep*, once replaced
on-screen by (say) the editing buffer of a *vi*, is gone for good. Since
*egrep* is not an interactive program, it is no longer around to be asked to
redraw its output.
The heart of the problem is that neither job control nor layers imple-
ments the crucial half of a window system: centralized management of screen
updates. It has long been accepted that multiple processes cannot safely do
updates to disks without centralized management and consistency control. The
same obviously applies to terminal i/o: orderly simultaneous interaction with
multiple processes requires centralized supervision of the interaction. The
existing schemes supervise input but not output.
It is obvious *why* this deficiency exists: supervising output is the
hard part. The idea of switching input from one program to another is reason-
ably straightforward. Differences in input handling, such as `cooked' vs.
`raw' modes, are relatively minor problems, since the user can be conversing
with at most one process at a time. But a CRT terminal permits output from
multiple processes to be displayed simultaneously, and coordinating screen
updates isn't trivial. Furthermore, there is no agreement on the precise user
interface that should be presented for output -- consider, for example, the
religious debates over overlapping vs. non-overlapping windows -- and this
discourages attempts to provide a single and relatively inflexible central
solution. The immense variation in CRT-terminal control sequences puts the
icing on the cake.
- 3 -
Nevertheless, these problems *can* be solved. There are at least three,
and probably several more, complete window systems in experimental use. Some
of them have performance problems, and most of them are outside the kernel and
hence have interprocess-communication problems, but they do work.
Standardizing Multiplexed Interaction: A Recommendation
As mentioned above, several experimental window systems already exist.
(This is quite apart from the `real' window systems on bitmapped workstations,
which are also relevant.) Experience with these and other implementations of
the same concept will yield a wealth of knowledge on how best to handle this
function. It is important that this experimentation, and the adoption of the
results that come out of it, not be stifled by further `official endorsement'
of incomplete and badly-designed existing schemes.
The best approach for P1003 to take on this matter would be to reserve
some characters, and some flag bits, for implementations of multiplexed user
interfaces, but not to specify any such interface at this time. Such an
attempt to specify the interface would be premature, especially when the two
approaches under consideration are already known to be grossly-incomplete
botches.
*Neither Berkeley `job control' nor AT&T `layers' is an adequate imple-
mentation of a multiplexed user interface*. *Neither one should be cast in
concrete as a standard at this time*.
A Retraction
Our previous recommendation was that, if multiplexed interaction *must*
be standardized, AT&T `layers' would be a better place to start. The layers
system, unlike Berkeley job control, does do input multiplexing more-or-less
correctly, and hence is essentially upward-compatible with true window sys-
tems. It has several desirable characteristics: independent tty state for
each layer, suspension/resumption invisible to the processes, a central
manager process which is *not* imbedded in a shell, and an implementation that
does not have ramifications everywhere.
Nevertheless, as discussed above, it doesn't do the hard part: output
multiplexing. It also has some annoying implementation limits, which,
although they wouldn't necessarily have to propagate into a standard, might
well propagate into most early implementations. Its major problem is that
it's not clear how to extend it to centralized output management without
imbedding said management inside the kernel.
We therefore retract our recommendation for standardizing layers as a
second choice. The proper course is to standardize nothing, at least until we
understand the user-interface issues and the implementation problems better.
Specifics
A decision not to standardize a multiplexed-interaction scheme notwith-
standing, there are a few useful minor things that can be standardized. The
*termio* structure probably should have a reserved character or two (or room
for same) and a few reserved bits (or room for same) to permit kernel-based
- 4 -
implementations of multiplexing.
In particular, almost any multiplexing scheme using ordinary ASCII termi-
nals will need a special character to attract the attention of the multiplex-
ing software. Without this, it's very difficult to do things like moving
between windows. Reserving space for such a character might be useful; recom-
mending a default choice for the character would be very valuable, as it would
forestall unnecessary differences between implementations. Control-Z would be
plausible.
Implementing supervision of multiplexed interaction in user processes is
difficult in many existing Unix implementations, minimal implementations of
the existing P1003 standard among them. The basic problem is that normal user
processes are definitely aware that their output is going to a terminal, the
device-independence of Unix i/o notwithstanding. Screen-oriented programs
doing *ioctl*s are the biggest problem. A less obvious glitch is that *stdio*
adjusts its buffering strategy depending on whether output is to a terminal or
not; this is a major nuisance with some existing window systems. Something
like the `pseudo-tty' concept would be very useful: an entity which looks
like a terminal from one side, but whose behavior is under user-process con-
trol from the other side. Some existing systems do implement such things, but
the lack of standardization largely prevents use of them in portable programs.
Suspending Processes: A Non-Issue
Several people have objected to AT&T layers, and similar approaches, on
the grounds that `...but 4BSD lets me suspend misbehaving processes...'. This
is silly; a process-suspension facility can be very simple if it isn't
required to double as a multiplexing system.
If it is thought desirable to standardize process suspension, we would
suggest the following. Some magic character (control-Y?), when typed as input
to a tty/window, suspends all processes attached to that tty/window. The
suspension can be, and should be, utterly invisible to the processes involved.
This avoids the sticky problem of how to notify the processes without doing
incompatible things to the *signal* mechanism. The suspension probably should
have a permission requirement analogous to that of signals: if the effective
userids of the user and the process don't match, the suspension doesn't hap-
pen. This is necessary to prevent major security breaches like suspending
*passwd*(1) in the middle of an update to the password file.
Note that this suspension facility isn't very useful in the absence of
multiplexed interaction -- you can't *do* anything to a suspended process
without access to another (real or virtual) terminal -- but the two concepts
are nevertheless quite independent. There is no need to confuse them.
Volume-Number: Volume 7, Number 30std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/09/86)
From: cbosgd!cbosgd.ATT.COM!mark@seismo.css.gov (Mark Horton)
Date: Thu, 9 Oct 86 01:30:59 edt
Organization: AT&T Bell Laboratories, Columbus
I've made significant use of four different sorts of systems
for multiplexing, so hopefully I can provide some feedback on
their relative merits, from a user's point of view.
(1) True windows, such as a 5620, Sun, UNIX PC, etc. Each window
acts like a terminal. This is unquestionably the best, but it
requires special hardware, and is an area that needs to be
standardized.
(2) A dumb-terminal window manager as Henry describes. I've written
such a window manager; on a system that has ptys, select, and a smart
curses package, it's easy (my code is only 700 lines.) It runs on both
4.2BSD and System V, provided that all three ingredients are present.
This package runs about as well as you could hope for, (the buffering
and ioctl problems Henry mentions are solved using ptys, and it doesn't
eat up much CPU time, and all my windows are the full 80 cols wide)
and I have a 60 line terminal so there's really room for two or three
windows. I use this rarely, because I dont' like the "mushy" feeling I
get from the screen management layer.
(3) Berkeley job control. Henry may think this is ugly, but from a user's
point of view, if you can't have a real bitmapped display, this is the
next best thing. I strongly prefer it to (2).
(4) System V shell layers. I don't use this very often, it's just not
very powerful and awfully inconvenient. It can't pop you out from any
program that runs in raw mode, such as cu or rlogin, because there's
no way for a program to suspend itself. rlogin really NEEDS to suspend
output in a non-window environment, otherwise your screen will be a mess.
I should mention that my major use of multiplexing is to switch between
rlogins to various other systems on our LAN, and a few local applications
such as vi, mail, and news. For situations where I really need two windows
(e.g. developing a network client and server) I strongly prefer to do it
on a true window system. It is possible that others, running other mixes
of applications, will feel differently.
My recommendation is, however, similar to Henry's, for the standard.
I don't think the dumb terminal window manager is the answer, but I
think it's clear we don't have the best answer yet, in general. I do
think that certain things should be standardized:
(a) termio, or at least the subset that's commonly used. You could always
put in a few high level subroutines like the cbreak/nocbreak echo/noecho
erasechar/killchar/baudrate routines in curses, just to provide a
portable interface.
(b) an ioctl to find out the current window size, in chars and pixels.
(c) a pty-like mechanism. (Streams may be a viable candidate here, or
Illinois/Berkeley ptys might be expedient.)
(d) a software-multiplexing mechanism, like select.
Mark
Volume-Number: Volume 7, Number 40std-unix@ut-sally.UUCP (10/10/86)
From: nike!oliveb!felix!peregrine!mike@sally.utexas.edu (Mike Wexler) Date: Thu, 9 Oct 86 10:21:55 PDT Organization: Peregrine Systems, Inc, Irvine Ca >From: pyramid!utzoo!henry@sally.utexas.edu (Henry Spencer) >Date: Sat, 4 Oct 86 03:03:30 PDT > > Implementing supervision of multiplexed interaction in user processes is >difficult in many existing Unix implementations, minimal implementations of >the existing P1003 standard among them. The basic problem is that normal user >processes are definitely aware that their output is going to a terminal, the >device-independence of Unix i/o notwithstanding. Screen-oriented programs >doing *ioctl*s are the biggest problem. A less obvious glitch is that *stdio* >adjusts its buffering strategy depending on whether output is to a terminal or >not; this is a major nuisance with some existing window systems. Something >like the `pseudo-tty' concept would be very useful: an entity which looks >like a terminal from one side, but whose behavior is under user-process con- >trol from the other side. Some existing systems do implement such things, but >the lack of standardization largely prevents use of them in portable programs. One idea would be to put Ritchie's streams in the standard or an extension of the standard so that there is a "clean" way of writing user level window managers. Given this there would probably be many window managers implemented and likes shells you wouldn't need a single standard one, but could provide several and allow users to write their own. [ Does anyone from the /usr/group networks or windowing systems groups have any comments on this? -mod ] Volume-Number: Volume 7, Number 45
std-unix@ut-sally.UUCP (10/10/86)
From: campbell%maynard.UUCP@harvisr.harvard.edu (Larry Campbell)
Date: Fri, 10 Oct 86 00:52:48 EDT
Organization: The Boston Software Works, Inc.
There's another flavor of terminal I/O multiplexing that Mark Horton
didn't mention. It's widely available today; it requires no changes
to user mode code (in fact, its presence is not detectable by user
mode code); it does not require bit mapped or graphics terminals; and
I've found it to be more useful and pleasant than I would have guessed.
"It" is the "virtual console" feature found in most PC-based UNIX
implementations. This does rely on memory-mapped video, but character-
mapped terminals work as well as bit-mapped ones. Typically, four to
ten function keys are used to select four to ten virtual consoles.
Each virtual console occupies the entire physical screen; you can
only see one at a time. Keyboard input goes to the current (visible)
virtual console. Since the video is memory mapped, switching is
instantaneous.
A process trying to write to a non-current virtual console will (fill
up some clists and then) block. A process trying to read the keyboard
will block until the user switches to its console and types something.
This is all completely invisible to user programs; they think they're
dealing with a perfectly ordinary 24x80 terminal. No SIGTSTP, no window
size ioctls, etc.
I've used several "true" windowing systems before (Xerox Star, Apple
Macintosh, Microsoft Windows, Symbolics 3600) and I find I like the
virtual console paradigm far more than I would have anticipated. It's
simple and uncluttered.
I'm not suggesting that virtual consoles become part of the standard;
just pointing out a useful alternative design.
--
Larry Campbell MCI: LCAMPBELL The Boston Software Works, Inc.
ARPA: campbell%maynard.uucp@harvard.ARPA 120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell (617) 367-6846
Volume-Number: Volume 7, Number 46std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/12/86)
From: guy@sun.com (Guy Harris) Date: Sat, 11 Oct 86 02:29:27 PDT > > Something like the `pseudo-tty' concept would be very useful: an entity > > which looks like a terminal from one side, but whose behavior is under > > user-process control from the other side. Some existing systems do > > implement such things, but the lack of standardization largely prevents > > use of them in portable programs. > One idea would be to put Ritchie's streams in the standard or an extension > of the standard so that there is a "clean" way of writing user level window > managers. Given this there would probably be many window managers > implemented and likes shells you wouldn't need a single standard one, but > could provide several and allow users to write their own. Streams don't in and of themselves provide a "clean" way of writing user-level window managers. As Henry pointed out, a pseudo-tty is what you want here; you have a window manager that simulates a terminal (using a real terminal or some other sort of display) and provides a tty-like interface to clients using a pseudo-tty. Streams might permit a fairly clean implementation of a pseudo-tty, but they don't provide the only clean way of writing user-level window managers; any sufficiently powerful pseudo-tty mechanism will do that. Streams might provide the cleanest way of providing a sufficiently powerful pseudo-tty mechanism. Volume-Number: Volume 7, Number 49
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/12/86)
From: guy@sun.com (Guy Harris) Date: Sat, 11 Oct 86 02:49:48 PDT > "It" is the "virtual console" feature found in most PC-based UNIX > implementations. This does rely on memory-mapped video, but character- > mapped terminals work as well as bit-mapped ones. No, you don't need a bit-mapped display to do windowing, but I presume most people already knew that. Convergent Technologies, for instance, has a windowing scheme on their PT terminals. It's not even a "virtual console" scheme; you can see parts of several windows, if you want. This sort of windowing mechanism doesn't even necessarily require a memory-mapped screen; it merely needs a way to redraw a window when it moves to the front. Mark Horton's earlier message describes a window manager for dumb terminals; it even permits more than one window on the screen. > A process trying to write to a non-current virtual console will (fill > up some clists and then) block. A process trying to read the keyboard > will block until the user switches to its console and types something. > This is all completely invisible to user programs; they think they're > dealing with a perfectly ordinary 24x80 terminal. No SIGTSTP, no window > size ioctls, etc. There's nothing particularly special about all this; other window systems do the same thing. Virtual consoles are just a special case of a window system where all windows cover the full screen. As for the window size "ioctl", consider this: any program that thinks it's always dealing with a "perfectly ordinary 24x80 terminal" is going to be quite surprised when run on an Ann Arbor Ambassador with 60 lines. Programs should not make assumptions like that. Given that the program will then have to query "termcap" or "terminfo" to find the size of the screen, it's not much trouble to have the routine that reads in the "termcap" or "terminfo" entry check what the window size "ioctl" says and only use the value in the entry if the window size is 0x0 (i.e., not specified). That's what Sun's "termcap" code does. Volume-Number: Volume 7, Number 50
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/12/86)
From: guy@sun.com (Guy Harris) Date: Sat, 11 Oct 86 03:05:09 PDT > (1) True windows, such as a 5620, Sun, UNIX PC, etc. Each window > acts like a terminal. This is unquestionably the best, but it > requires special hardware, and is an area that needs to be > standardized. At some point, perhaps. It's unclear whether now is the time to do so. I don't think window systems have been around long enough that people can say "this is how to do a window system". I don't think window systems have settled down enough to start standardizing yet. (How many people would have thought of using PostScript as a rendering language for a window system, and extending it to handle input events as well and act as an extension language, before James Gosling first talked about his work? Would people have missed that entirely when developing a standard?) Also, what would the standard specify? A C-language binding to routines to manipulate the screen? A set of low-level operations to render images within a window, a high-level user interface toolkit, something in between, all of the above, or none of the above? > (3) Berkeley job control. Henry may think this is ugly, but from a user's > point of view, if you can't have a real bitmapped display, this is the > next best thing. I strongly prefer it to (2). For what it's worth, I will point out that even though I have access to (1), I still use (3). I haven't analyzed my use of it enough to really say why. Some of it may be that it takes a while to pop up a new shell window in my environment (time to start the window process that provides the simulated terminal and time to start up the Korn shell). Some of it may be that the EMACS key bindings I have let me suspend EMACS but not easily fork off a new shell. Some of it may be that it is occasionally convenient to move a job into the background when you discover it'll take a while to complete, or move a backgrounded job into the foreground to abort it. > I do think that certain things should be standardized: > (a) termio, or at least the subset that's commonly used. The current proposal before 1003.1 does this; it fixes some botches in "termio" as it exists (MIN and TIME are not overloaded with EOF and EOL, for instance) and restores a couple of capabilities deleted when the System III terminal driver first appeared. > (b) an ioctl to find out the current window size, in chars and pixels. The current proposal has this, but does not give the window size in pixels. The "termio" interface is really not a good portable interface for doing graphics, since most terminals can't do graphics. As such, it's not clear why the window size in pixels should be provided by this interface. A program that really cares how big the window is in pixels should probably use the local window system primitives for this, since it has to use the window system's rendering primitives to draw things anyway. Volume-Number: Volume 7, Number 51
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/14/86)
From: cbosgd!cbosgd.ATT.COM!mark@seismo.css.gov (Mark Horton) Date: Sun, 12 Oct 86 23:50:46 edt Organization: AT&T Medical Information Systems, Columbus The virtual screen stuff, such as UNIX or Xenix on a PC have, should be considered a poor cousin of a true bitmapped window capability. Aside from losing the ability to watch two windows at once, they are essentially the same. Both are nice, neither is an alternative for anything except a personal computer or workstation. By the way, another possibility has been suggested: something like System V's shell layers, but using scrolling regions in a vt100 or similar terminal to lock the terminal into the appropriate window. You lose the ability to see async updates in another window, and you still need ptys and select, but you don't need curses, and you shouldn't get the mushy feeling. Something would have to be done about ^Z not working in raw mode, so you could break out of an rlogin or cu or vi. One way to do this would be something like Berkeley's TIOCSTI, so the program can detect the situation (using a multi-char escape sequence), take itself out of raw mode, and type the ^Z itself. (Henry's complaint about user programs having to be modified is a minor one, in my opinion. A program that isn't screen oriented needs no modification. A program that is screen oriented can use curses, and curses can catch the signal and redraw the screen as needed. The only programs that need modification are those that have to be transparently able to pass ^Z through, this mostly means remote login programs, and they need this kind of capability without job control anyway.) >From: guy@sun.com (Guy Harris) > >> (1) True windows, such as a 5620, Sun, UNIX PC, etc. Each window >> acts like a terminal. This is unquestionably the best, but it >> requires special hardware, and is an area that needs to be >> standardized. > >At some point, perhaps. It's unclear whether now is the time to do so. I did not mean to imply that it should be standardized NOW, although I think the field is starting to generate enough examples that it would be worthwhile for someone to start looking at it. We certainly aren't ready to put it into P.1003 yet. What I meant is that certain common elements should be standardized, in particular, the ioctl to get and set the current window size. These all look the same, but with different particulars. >> (b) an ioctl to find out the current window size, in chars and pixels. > >The current proposal has this, but does not give the window size in pixels. >The "termio" interface is really not a good portable interface for doing >graphics, since most terminals can't do graphics. As such, it's not clear >why the window size in pixels should be provided by this interface. The reason I mention pixels is that many of the existing ioctls seem to bundle the pixel numbers and char numbers into the same ioctl. Perhaps it does make sense to separate them. By the way, I think both "get" and "set" operations should be standardized, and the standard should state that both ioctls must work on both sides of the pty. (This assumes we can appropriately specify what a "pty" is.) The "get" operation can indeed be isolated into tgetnum (termcap) and setupterm (terminfo.) But lack of standardization means that the sources to termcap and terminfo have to be cluttered up with umpteen different ways to do the same thing. The "set" operation is needed for window managers, and also so there can be a shell command to set the window size when the system gets it wrong. (The system gets it wrong a lot in practice, all you have to do is remote login through a link that doesn't pass the window size, such as cu, telnet, or 4.2's rlogin. (4.3 passes the size.)) Sometimes windows get resized, too, so it would be useful for the cu/rlogin program to be able to send a shell command through when this happens.) Mark Volume-Number: Volume 7, Number 55
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/14/86)
From: shannon@sun.com (Bill Shannon) Date: Sun, 12 Oct 86 22:37:40 PDT > From: cbosgd!cbosgd.ATT.COM!mark@seismo.css.gov (Mark Horton) > > ... > > (b) an ioctl to find out the current window size, in chars and pixels. I've argued this with the people at Berkeley and lost, but I'll try again here. I don't believe there should be an ioctl to find out the pixel size of a "window". This seems to me to be the wrong way to retrieve this information. The pixel size is of no use to programs that deal only in characters. Only programs manipulating windows will need to know the pixel size. Whatever mechanism is used to manipulate window should also be used to find out the pixel size of the window. (Of course, this may be, but is not required to be, ioctl's.) The tty subsystem, which deals only in characters, should not know anything about pixels or windows. Bill Shannon Volume-Number: Volume 7, Number 57
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/14/86)
From: campbell%maynard.UUCP@harvisr.harvard.edu (Larry Campbell) Date: Sun, 12 Oct 86 11:43:38 EDT Organization: The Boston Software Works, Inc. In article <5990@ut-sally.UUCP> guy@sun.com (Guy Harris) writes: >This sort of windowing mechanism doesn't even necessarily require a >memory-mapped screen; it merely needs a way to redraw a window when it moves >to the front. Mark Horton's earlier message describes a window manager for >dumb terminals; it even permits more than one window on the screen. Of course, but I suspect that redrawing windows over a serial line would be tedious -- unless the serial line were running at 56KB or better. >As for the window size "ioctl", consider this: any program that thinks it's >always dealing with a "perfectly ordinary 24x80 terminal" is going to be >quite surprised when run on an Ann Arbor Ambassador with 60 lines. Programs >should not make assumptions like that. That was an oversimplification on my part. Of course programs should (and most do) query termcap/terminfo. However, they can safely assume that the window size isn't going to change while they're running, and this assumption reduces complexity. -- Larry Campbell MCI: LCAMPBELL The Boston Software Works, Inc. ARPA: campbell%maynard.uucp@harvard.ARPA 120 Fulton Street, Boston MA 02109 UUCP: {alliant,wjh12}!maynard!campbell (617) 367-6846 Volume-Number: Volume 7, Number 58
std-unix@ut-sally.UUCP (10/17/86)
From: bobr%zeus.tek.csnet@RELAY.CS.NET (Robert Reed) Organization: CAE Systems Division, Tektronix Inc., Beaverton OR Date: 15 Oct 86 12:23:31 PDT (Wed) > From: shannon@sun.com (Bill Shannon) > I don't believe there should be an ioctl to find out the pixel size of a > "window". ... The pixel size is of no use to programs that deal only in > characters. Only programs manipulating windows will need to know the pixel > size. ... The tty subsystem, which deals only in characters, should not > know anything about pixels or windows. Naive programs should have access to window size as character information, but there are programs which do not manipulate windows which need window size information in pixels. My solution would be to provide the size in character units but also provide character cell size in pixels with the same call (ioctl or whatever). Programs could use it or ignore it. Whether the tty system does know about pixels or not, it should. If the window size information (in character units) is going to be accurate, window sizes must be restricted to integrals of character size. With straight ttys this is no problem, but if the system supports font changing, character size can vary. Rather than require one call to find the window size and then another call to find out what the units are, this information should be consolidated into a single place. Volume-Number: Volume 7, Number 64
std-unix@ut-sally.UUCP (10/17/86)
From: bobr@zeus.UUCP (Robert Reed) Organization: CAE Systems Division, Tektronix Inc., Beaverton OR In article <6004@ut-sally.UUCP> Larry Campbell <campbell%maynard.UUCP@harvisr.harvard.edu> writes: > Of course programs should (and most do) query termcap/terminfo. However, > they can safely assume that the window size isn't going to change while > they're running, and this assumption reduces complexity. Programs cannot safely assume that window size is not going to change, because on most overlapped window management systems it will. It is just too easy to set inappropriate window sizes and then need to adjust them. Consider creating a new which is almost the right size (say 75 characters wide) and then invoking an editor on a file of 80 character data. The editor will either wrap or truncate the data, and changing the window size to compensate will do nothing but frustate the user. What is needed is something like 4.3 BSD's WINCH signal, to advise those applications which care about such changes. -- Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK Volume-Number: Volume 7, Number 65
std-unix@ut-sally.UUCP@ndmce.uucp (Moderator, John Quarterman) (10/18/86)
From: guy@sun.com (Guy Harris) Date: Wed, 15 Oct 86 11:18:03 PDT > What I meant is that certain common elements should be standardized, > in particular, the ioctl to get and set the current window size. > These all look the same, but with different particulars. This isn't really just a window system issue; the current "termios" proposal avoids referring to it as a "window" size. One could imagine features, such as end-of-"page" pauses in the TTY driver, that would use this information even on dumb terminals. > By the way, I think both "get" and "set" operations should be standardized, > and the standard should state that both ioctls must work on both sides of > the pty. (This assumes we can appropriately specify what a "pty" is.) The "set" operation is in the "termios" proposal; since "pty"s aren't, it doesn't say anything about whether the operation works on both sides or not. Volume-Number: Volume 7, Number 61
std-unix@ut-sally.UUCP (10/20/86)
From: pyramid!allegra!cbosg!osu-eddie!bgsuvax!schaefer (Stephen Schaefer) Date: Thu, 16 Oct 86 13:05:33 edt I'd like to offer some observations from my experience concerning windows. I am very comfortable using the wm window manager (by Robert Jacob, enhanced by Matt Lennon and Tom Truscott). The present design relies heavily on pty's and the 'select' call of 4.[23]BSD. I use a 9600 baud line with a 24*80 screen, which is quite sufficient. I feel no need at all for bit-mapping until I want to draw pictures, or preview some typesetting, which has nothing to do with windows. I'm guessing that it takes about half a second to repaint my screen - the same amount of time as vi takes to show the next screen full. Far more often, the window simply scrolls. I had a chance to work with a 5620 for a while. While I was directly connected at 9600 baud to a 4.2BSD 11-780, I told it to act like a VT100 with a 70*88 screen. I was more than happy - for editing, I used the whole screen, for shell interaction I used a half screen to cut down on update time, and because I'm usually working on a minimum of two things at once. Ghosting of the phosphor was far more of a problem than speed. I also used the 5620 with a 3B2, shell layers, and a mouse. Pulling windows around was fun for a while, but it never became important to me, the way switching from window to window has. The bit mapping was good for drawing pictures and previewing typesetting, but I never saw what it had to do with windows. I haven't mentioned job control yet - I use it when it's available. I very often want a process to freeze until I find it convenient to get back to it. I am willing to entertain the possibility that windows could take over much of that function, but when I suspend, I am usually thinking "suspend", and it would take some thought (or re-conditioning) to consider switching windows. A second consideration is that I use GNU emacs, and it significantly faster to ^Z and fg than to quit and restart. I don't understand the accusations that ^Z is a "kluge", unless these people are referring to the implementation, which I haven't studied. It was utterly clear, from the first time someone showed it to me: hit ^Z, ask to see your jobs, now choose how or if to continue them (in foreground or background), but be assured that they are still there until you dispose of them. I survive without it when I don't have it, but I use it when I do have it. In sum: windows are good for multitasking *me*, and appear to depend on pty's and maybe select(2). Bitmapping is good for pictures, but is irrelevant to a purely text environment - which is where I am almost entirely. Job control is good for suspending processes, and is nice for avoiding the load time of large programs. The three are independent facilities. An expensive, full-featured system would have all of them. Less expensive systems could be missing one or more of them and still be Un*x. If I had to choose the most valuable one it would be pty's, but that is probably just my taste. Volume-Number: Volume 7, Number 74
std-unix@ut-sally.UUCP (10/27/86)
From: shannon@sun.com (Bill Shannon) Date: Sat, 25 Oct 86 00:19:53 PDT > From: bobr%zeus.tek.csnet@RELAY.CS.NET (Robert Reed) > Organization: CAE Systems Division, Tektronix Inc., Beaverton OR > Date: 15 Oct 86 12:23:31 PDT (Wed) > > Naive programs should have access to window size as character information, > but there are programs which do not manipulate windows which need window > size information in pixels. I'm still waiting to hear about such programs that aren't dependent on the particular window system they are running under. > Whether the tty system does know about pixels or not, it should. If the > window size information (in character units) is going to be accurate, window > sizes must be restricted to integrals of character size. With straight ttys > this is no problem, but if the system supports font changing, character size > can vary. Rather than require one call to find the window size and then > another call to find out what the units are, this information should be > consolidated into a single place. If you want both at once, the window system can do the consolidation. The tty driver should not know about pixels. Bill Shannon Volume-Number: Volume 7, Number 92
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (10/31/86)
From: seismo!mcvax!jack
Organization: AMOEBA project, CWI, Amsterdam
Last-Band-Seen: Eton Crop, That Petrol Emotion (Paradiso, 30-09).
Opinion-Of-Them: Two good and honest guitar bands....
Date: Tue, 28 Oct 86 23:39:03 +0100
I waited for some time, thinking someone else would point this out,
but nobody did, so here goes:
*CURRENT JOB CONTROL IMPLEMENTATIONS ARE HORRIBLE. HORRIBLE!
HORRIBLE!!!!!!!!*
After reading David Lennart's (sp?) article on 4.2 job control,
SYSV shell layers, and HP-UX's hybrid I was shocked, I must admit.
Both solutions are filled with horrible tricks like closing
tty's and re-opening them and then doing funny ioctl()s and the closing
them again and then reopening then and then...
It is of course a praiseworthy feat that the folks at HP managed to
sqeeze those two horrible, inconsistent, unintellegible mechanisms
into one poor kernel, but I'm afraid the result is horrible**2.
I think that, if nobody can come up with a nice&clean subset of
job control facilities, that will allow sysV and BSD semantics to
be implemented on top of them, we should forget about standardising
anything. Standardising bad mechanisms will only hinder progress
(Did I hear someone say F77? X25?).
>From now on, you can find me in the "job control is horrible" camp.
--
Jack Jansen, jack@mcvax.UUCP
The shell is my oyster.
Volume-Number: Volume 8, Number 10std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/02/86)
From: seismo!vrdxhq!inteloa!omepd!jimv (Jim Valerio) Organization: Intel Corp. Hillsboro, Oregon Date: Wed, 08 Oct 86 14:59:16 -0800 I object to one claim made by Henry Spencer on job suspension: >Note that this suspension facility isn't very useful in the absence of >multiplexed interaction -- you can't *do* anything to a suspended process >without access to another (real or virtual) terminal -- but the two concepts >are nevertheless quite independent. There is no need to confuse them. Completely independent of terminal interfaces, job suspension is a useful feature. In particular, I have a batch queue mechanism in mind on 4.2bsd UNIX which suspends batch jobs when the interactive load gets too high, and restarts them (sending SIGCONT) when the interactive load drops again. This control can be done both by an operator and by a daemon, and has no notion of controlling terminal for the batch job. As Henry indicates, job suspension and multi-process control are two different items. Even though job control may not be the only or best way to implement multi-process control, job suspension is an important feature in its own right. -- Jim Valerio ogcvax!inteloa!omepd!jimv, tektronix!psu-cs!omepd!jimv Volume-Number: Volume 8, Number 15
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/05/86)
From: seismo!hadron!jsdy@sally.utexas.edu (Joseph S. D. Yao) Date: Tue, 4 Nov 86 22:47:30 est Organization: Hadron, Inc., Fairfax, VA In article <6176@ut-sally.UUCP> you write: >From: seismo!mcvax!jack >Organization: AMOEBA project, CWI, Amsterdam >Date: Tue, 28 Oct 86 23:39:03 +0100 > >*CURRENT JOB CONTROL IMPLEMENTATIONS ARE HORRIBLE. HORRIBLE! >HORRIBLE!!!!!!!!* >Both solutions are filled with horrible tricks like closing >tty's and re-opening them and then doing funny ioctl()s and the closing >them again and then reopening then and then... >It is of course a praiseworthy feat that the folks at HP managed to >sqeeze those two horrible, inconsistent, unintellegible mechanisms >into one poor kernel, but I'm afraid the result is horrible**2. >>From now on, you can find me in the "job control is horrible" camp. Jack, one gets the vague feeling you dislike these implementations, without the least notion why. Could you please meditate, or take a pill, or whatever soothes you, and then tell us exactly why you feel this way? (You may wish to take frequent mellow breaks.) Perhaps you could also tell us what you feel defines a non-horrible job control implementation. Thank you! -- Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP} jsdy@hadron.COM (not yet domainised) Volume-Number: Volume 8, Number 41
std-unix@ut-sally.UUCP (Moderator, John Quarterman) (11/09/86)
From: ihnp4!iwtpu!katzung (Brian Katzung)
Date: Sat, 8 Nov 86 14:59:33 CST
I guess I'm being sort of lazy... I haven't even figured out the
relationship between "P1003" and "POSIX" (I got in late on the discussion),
[ IEEE P1003 is the committee; P1003.1 is the subcommittee that produced
the POSIX Trial Use Standard. -mod ]
but I wanted to point out one shortcoming of the 4.xBSD implementation of
job control so that it might be avoided in the future.
The wait3 system call has provisions for informing the parent when a
child is suspended, but not when it resumes. Thus, if an agent other than
the parent resumes the child, the parent doesn't know about it. This is
rare, but not unimaginable. I've had applications that could have been
enhanced if the mechanism were "balanced".
I haven't checked 4.3, but the 4.2 csh, in particular, won't send a
STOP or TSTP to a process that it believes is already stopped.
-- Brian Katzung ihnp4!{laidbak,iwtpu}!katzung
Volume-Number: Volume 8, Number 51