Re: HeathField Strange Ideas!

In article <Jnpx7w.GJD@xxxxxx>, *** T. Winter <***.Winter@xxxxxx> wrote:
In article <u5edncFI5dpEvkTbnZ2dnUVZ8t-nnZ2d@xxxxxx> "Malcolm McLean" <regniztar@xxxxxxxxxxxxxx> writes:

I can be made topical. "How should we go about writing a portable C console
interface?"

This has a lot of undefined things in it. As I read it, I understand an
interface that can be included in a program so to interface with the
console where the user is currently touching the keys. To that the
answer is: it can only be done if the application is running on the
same computer that connects to the computer, and even then it is not
necessarily possible.

I'll add a little to the confusion -- and where there is confusion,
there is unlikely to be portability ;-)

On the great majority of modern desktop/laptop computers (and even of
those 15-ish years old), the keyboard does not emit a stream of
characters: instead it emits a stream of events, such as
"Left-shift pressed", "key #58 pressed", "key #58 pressed",
"left-shift released". Traditionally, if you are -directly- using
MS Windows, or a system with X Windows, a standardized version of those
events can be made available to the GUI (e.g., the GUI might receive
an encoding of "Keypad +" instead of "key #58"); even the raw events
are often available if you dig deep enough with those window systems.
And with X at least, the events can even be made available to remote
systems.

But there is no industry-standard method for programs to receive
these keyboard (or mouse) events; X is an official standard, used
by quite a number of systems, and MS Windows is a de-facto standard,
probably used by even more systems (in terms of sales, not in
terms of diversity), and they are not compatible: a program written
to interface to an X system would use very different calls than a
program written to interface to MS Windows. "Shims", to allow a
program coded for one event schema to be used with another, are
pretty uncommon too; certainly products such as Hummingbird's eXceed
exist, but that is a complete implementations of X, graphics and
all, not just a library or DLL that one can link against and gain
compatability cheaply.

What the C standard deals with is *character streams* (or byte
streams, if one is working in binary). Character streams are
the fully decoded output of keyboard events, with information
about modifiers and key presses and releases transformed into
ASCII or ISO 8859-1 or UTF-8 or Windows-1292 or the like.
There *are* standardized ways of handling many character-related
tasks (though tranforming between character sets could apparently
use some improvement at the C standard level), and there *are*
standardized ways of transmitting characters to remote systems,
or to virtualized systems.

Now, as events are what systems actually receive from keyboards,
it would be possible, in theory, to design an industry standard
(or at least "recognized" if not quite standardized) schema for
transmitting keyboard events between systems. Any such schema would,
of necessity, have to be flexible, to be able to gracefully
handle keyboards that lack certain capabilities (e.g., perhaps
the keyboard only emits key-up events and not key-down events
as well); the schema would also have to encompass systems that
deal strictly with fully-decoded character streams.


All this to address ***'s note that,

it can only be done if the application is running on the
same computer that connects to the computer

That is, my counter-argument is that it -can- (many times) be done
if the application is running on a -different- computer than the
keyboard is connected to; it is routinely done for X.


But, to emphasize for clarity: any schema that were developed
for dealing with (possibly-remote) keyboard events should *not*
(IMHO), be part of the C standard. Yes, it would be nice for
users of such a schema to be able to count on it being in place, but
on the other hand, I believe it would be too much of a burden upon
systems that cannot or should not use such a facility. And it
might start getting into issues such as key press timing;
pretty much anything to do with precision timing is outside the
realm of what C itself handles.
--
If you lie to the compiler, it will get its revenge. -- Henry Spencer
.