Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!texsun!pollux!killer!chasm
From: chasm@killer.DALLAS.TX.US (Charles Marslett)
Newsgroups: comp.os.minix
Subject: Re: job control is a bug, not a feature
Summary: Hear, Hear
Message-ID: <8336@killer.DALLAS.TX.US>
Date: 10 Jun 89 15:53:14 GMT
References: <16497@louie.udel.EDU> <11989@bcsaic.UUCP> <2775@munnari.oz> <1989Jun10.063315.26085@utzoo.uucp>
Organization: The Unix(R) Connection, Dallas, Texas
Lines: 27

In article <1989Jun10.063315.26085@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) writes:
> >the best solution is to allow multiple windows, and job control within
> >each...
>
> Why provide two ways of doing the same thing?  See Ken Thompson in the
> original Unix papers on the virtues of doing things only one way.

What this all boils down to, I think, is that a window manager has to do
all the things job control does, and some even allow programs written with
no knowledge of the window manager's operation to run.  Job control on the
other hand, is a subset of the window manager's functionality, so it must
be either replaced (as I understand the normal scheme of things handles it)
or the duplicate functions trip all over each other when you add a windowing
scheme.

The primary issue I would like to raise is how much of a performance hit do
you get by adding the window manager to the screen output/keyboard input path
over having the simpler job control scheme.  I do not mean X11 or whatever, just
an OS/2 style monitor to map I/O to various "logical windows".  Has anyone
ever done this?

> -- 
> You *can* understand sendmail, |     Henry Spencer at U of Toronto Zoology
> but it's not worth it. -Collyer| uunet!attcan!utzoo!henry henry@zoo.toronto.edu

Charles Marslett
chasm@killer.dallas.tx.us