Xref: utzoo comp.lang.c:36698 comp.std.c:4409
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-picayune.mit.edu!news
From: scs@adam.mit.edu (Steve Summit)
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: Keyboard support in C (was Re: making characters disappear)
Message-ID: <1991Mar2.065232.1637@athena.mit.edu>
Date: 2 Mar 91 06:52:32 GMT
References: <1991Feb23.170142.538@ux1.cso.uiuc.edu> <15302@smoke.brl.mil> <14542@ganymede.inmos.co.uk>
Sender: news@athena.mit.edu (News system)
Reply-To: scs@adam.mit.edu
Organization: Thermal Technologies, Cambridge, MA
Lines: 115

mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:
>That is because it SHOULD be possible to do such very common things
>as non-echo reading or reading single characters without terminating
>carriage returns. We should be discussing how to put this into the
>next standardized version of the language. It SHOULD have been in the
>present version. 

In article <14542@ganymede.inmos.co.uk> conor@inmos.co.uk (Conor O'Neill) writes:
>I agree strongly with Doug McDonald.
>Since all computers which support files almost certainly have a keyboard,
>it would seem sensible to provide for keyboard access within ANSI C.
>It also seems, because of the frequency with which this question occurs,
>that it is exactly the sort of problem which it would have been useful
>to standardise, so that it would be possible to write interactive
>programs which were at least portable to machines and operating systems
>with `normal' keyboards.

Oh, for heaven's sake.  Have either of you read the frequently-
asked questions list carefully?  I realize that the answer that's
in there isn't the one you like, but there's also a brief
explanation of *why* that has to be the answer.  The frequently-
asked questions list isn't just to answer frequently asked simple
questions, it's also supposed to lay some of these interminable
debates to rest.  (Don't worry; I harbor no illusions about the
likelihood of that ever really happening.)

The point has been made approximately 2,974 times, but if you
want a standard which defines controls over terminal driver
characteristics, GO READ POSIX.  X3J11 didn't just decline to
address this issue because some operating systems wouldn't be
able to support the desired functionality, it also declined to
address it because it had been explicitly yielded to IEEE 1003.1
to handle.

Whenever this issue comes up, someone volunteers to define a
simple interface for controlling the most popular terminal driver
modes, which could be widely implemented using the services which
various operating systems provide.  I've made this suggestion
myself, at least once; now I'm just annoyed enough that I'm going
to spend an hour and cobble one together.  Now, the fact that
this package will have an hour or so of work put into it should
tell you two things:

     1.	it wouldn't be very hard for a program which needs to do
	these things to do them itself, and

     2.	this package isn't going to come close to addressing the
	sorts of complicated functionality that complicated programs
	want.  No specification, short of a full terminal driver
	definition in an operating system specification (such as
	Posix) could do so.  (In fact, terminal driver definitions,
	no matter how overladen with features, are notorious for
	being found inadequate by demanding application programs.)

To use this simple package, a program must #include "ttyio.h",
and call tty_init.  It can then call tty_setmode to control tty
operating modes (only two are defined: character-at-a-time-ness
and echo), and tty_getchar to read single characters.  tty_navail
reports the number of characters immediately available, if known.
tty_reset cleans up the terminal driver before exiting.

A separate posting (in comp.lang.c and/or alt.sources) contains
implementations for V7/bsd Unix, curses, and MS-DOS, as well as a
dubious, untested implementation for Posix.  (The MS-DOS version
has been tested under Microsoft C, but I believe most if not all
PC C RTL's supply getch and kbhit.)  A System V version would
probably be very close to Posix, but I don't have access to a
System V system for testing.  It has been several years since I
worked with VMS, and I have forgotten the details of its terminal
driver, so I won't be able to provide a VMS implementation at the
moment.

It should be obvious, but it probably isn't, so I'll point out
a couple of things:

     1.	This package isn't perfect.  It isn't supposed to be.
	There are _lots_ of ways the names and functionality
	could be changed.  (*Please* don't post, or even send me
	mail, informing me of any of its limitations.  I know of
	them, lots of them, on many levels.)

     2.	This package is not intended to be, and never will be,
	any kind of standard, formal or informal.  If you want to
	use it, put it in with your application's sources. 
	That way, you can modify it to your heart's content; you
	don't have to worry about keeping the interface
	compatible with anyone else's copy.

Think about these two points carefully.  This is the kind of
simple interface package everyone keeps asking for.  But it
probably isn't adequate for anyone's needs, let alone everyone's.
(I just wrote it, and I doubt I'll ever use it.)  You are going
to see things in this package you'll need to change.  Everybody
who looks at it is going to see things they'll need to change.
No one would use it, as is, to write anything more complicated
than the test program that comes with it.  By the time enough
features got added to it to make it generally usable by real
programs, it wouldn't be simple any more, many of its features
wouldn't be implementable under one operating system or another
(its tty_navail already falls into that category), and it still
wouldn't satisfy everyone.  (On the other hand, if I'm wrong, and
this package is just what you need, then by all means use it.)

It isn't really possible to address this issue simply (unless you
do so pedagogically, as this package does).  That's why X3.159
doesn't have any terminal driver stuff in it, and why nothing
short of a full terminal driver definition in an operating system
specification can usefully do so.  If someone wants to try
writing a Posix terminal driver emulator for older versions of
Unix, or for VMS, or for MS-DOS, with some kind of indication to
the calling program of which Posix features are/aren't emulated,
that would be an, er, "interesting" project (to say the least).

                                            Steve Summit
                                            scs@adam.mit.edu