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: <1640@rlgvax.UUCP> Date: Wed, 1-Feb-84 03:35:12 EST Article-I.D.: rlgvax.1640 Posted: Wed Feb 1 03:35:12 1984 Date-Received: Tue, 7-Feb-84 09:19:20 EST References: <794@omsvax.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 83 > (An aside, was I halucinating or were people REALLY booing > the presenter?) No, you were not hallucinating. > Anyway, my questions: > 3) You can't signal a process to tell it to 'repaint' > the screen with the V.2 JC stuff. Is there anyway to get > around that? No. That is one reason people were booing the presenter. > 4) The presenter (cant remember who) made the comment that > the Berkeley JC had severe problems with its definition. > I've never loved the implementation but isn't the problem > in the implementation rather than the definition? I don't remember what the comment was, but it is interesting to note that most UNIX programs (all those which don't put the terminal or the tty channel in a non-standard mode or move the cursor other than by outputting lines) don't have to change *at all* to work with job control. Those that print a prompt *can* be changed (it improves their esthetics), but *need* not be. Screen editors probably don't *have* to be changed, either, but they're a *lot* nicer if they do - if they don't, they give the same inadequate behavior as the S5R2 "job control" does. > 5) The comment was made (by the presenter) that his JC stuff > is a poor mans BLIT. Why then is it called job control when > it is more a primitive window manager (complete with virtual > ttys!!)? It's called "job control" because, to some degree, it's a marketing ploy. It is truly a primitive window manager; you can't "control jobs" by stopping them. It also has no way of notifying the program that it has had control of the terminal taken away from it, which means that any program which assumes that it has total control of some terminal, either physical or virtual, won't work unless the virtual terminal mechanism is modified to track all the changes to the terminal state made by that program and to always switch the state of the physical terminal to match the state of the currently active virtual terminal. This would mean it would have to keep a *FULL* screen image, and keep track of all sorts of internal state for the virtual terminal. This either means it has to know everything about every model of terminal anyone would ever hook up to a system running S5R2, or it has to provide a "virtual terminal" which is a powerful enough model to be sanely emulated on every model of terminal anyone would ever hook up to a system running S5R2. In short, to do it "correctly" would mean implementing a gigantic package which would dwarf "curses" in complexity either inside the kernel or in a process connected to all terminals using the virtual terminal facility with a multiplexed-file like facility; I'm not even sure this is implementable given the variety of terminals out there. So any claims by Bell that this is the "correct" way to do it, as opposed to the Berkeley method which is "incorrect", are bogus. The Berkeley method distributes knowledge about the peculiarities of the terminal to the programs using the terminal; the Bell method tries to centralize this knowledge but fails because the only such knowledge that it centralizes is the "ioctl"-settable tty port modes. Consider the "ged" program - a Graphical EDitor, supplied with S3 and S5, for the Tektronix 4014 - modified to work on a "VT100-plus-graphics-board" terminal which has a VT100 mode and a separate TEK4014 emulation mode. Now try to imagine this running on a "virtual terminal" using the S5R2 virtual terminal facility. Can you say "totally scrambled screen?" I thought you could! The "layer shell" doesn't know doodley about turning the TEK4014 emulation mode on or off. You would have to implement commands in "ged" to turn emulation mode off and clear the screen, and to turn emulation mode back on and redraw the screen. Then, you would have to run the first command before switching out of that layer and run the second command before switching into that layer. But why not just have a signal sent to the program which tells it that its layer is being left or entered? Then the program could automatically run those commands which would make the user interface to the layers facility infinitely superior (less chance for errors, less typing, etc. - "cleaner and simpler but much more of a pain to use" is usually *not* a win). Well, that's what SIGSTOP and SIGCONT are for in the Berkeley job control mechanism. It sounds like they adapted an idea that wins on the Blit (because the Blit is specialized hardware and software *designed* so that a virtual terminal idea will work) and tried to make it work on arbitrary hardware. Given how arbitrary terminals can be, I'm not surprised that such an attempt failed. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy