Human vs. machine input (was: Re: Behaviour of setjmp/longjmp ...)

[Leslie Mikesell]

In article <1016 at auspex.UUCP> guy at auspex.UUCP (Guy Harris) writes:
>>>Perhaps we should begin to make a really SERIOUS distinction between
>>>direct human input and other kinds.

>Right.  So all OSes that don't let you do that are "fairly useless". 
>Funny, lots of people seem to have uses for them....

Yes, to run monolithic applications.  Unix could do that too, I suppose..

>It's also not clear how the "don't distinguish" model applies to
>window-system-style tools, where input doesn't necessarily consist of
>the sort of stuff you'd stuff into a text file.

How do you write programs to manipulate the stuff, then?  As a programmer,
I prefer to *eliminate* human input rather than optimizing it.  Obviously
I don't do freehand graphics.

>>Imagine wc working only with typed input - how often would you use it?
>Lousy example.  "wc" takes all its *commands* (i.e., "count characters",
>"count words", "count lines") from the command-line arguments;

But it illustrates the point I was trying (and apparently failed) to make.
I don't object to fancy interfaces, but they should be a "front-end" that
generates a standard interface for other tools. 

>None of the systems I've worked with "waste" much CPU time "watching"
>for "meaningless" transitions of the <shift> key; on Suns, for example,

Try executing sar on a '386 machine running VP/ix with a DOS process
active.  Note that the idle time is 0.  Perhaps keyboard scanning is
not entirely to blame - does the Sun 386i handle DOS better?

Les Mikesell