job control

[std-unix at ut-sally.UUCP]

From: campbell%maynard.UUCP at 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 at harvard.ARPA   120 Fulton Street, Boston MA 02109
UUCP: {alliant,wjh12}!maynard!campbell     (617) 367-6846

Volume-Number: Volume 7, Number 46