Re: ISO VT320 emulator with key-bindings for Oracle Forms

peter_at_baileynm.com (Peter da Silva) wrote:
: In article <7jjshc$ere$1_at_newsmaster.cc.columbia.edu>,
: Frank da Cruz <fdc_at_watsun.cc.columbia.edu> wrote:
: > ...
: > b. Inconsistent among different UNIX platforms and versions (e.g. the
: > APIs differ -- even a simple function like tputs() has practically
: > infinite combinations of return type and argument types, thus preventing
: > any program that uses it from being portable without including hundreds
: > of #ifdefs);
:
: I haven't run into this problem, and I've written and ported an awful lot of
: curses-based code between UNIX systems. Some code did a good job of
: encapsulating the slight differences between implemetations of the termlib
: API, and other code made no attempt to hide system dependencies and just
: scattered ifdefs all over the place. Even otherwise well-written code like
: early versions of Kermit had that problem.
:

tputs() can be void or int. The third argument of tputs(), which is a pointer to a function to put a character, can be void, int, or char. The argument to that function can be void or char. Thus there are at least 2 x 3 x 2 = 12 combinations that must be accounted for in any portable code that uses tputs(). Probably more like 30 when you take into account that int or char can be signed or unsigned. Of course the ugliness is encapsulated, but that doesn't make any less ugly. I have never understood the force impels UNIX implementors to change data types of widely used APIs every time they get a chance.

: > c. Dependent on buggy and/or incomplete databases;
:
: That's something the end-user can fix.
:

If the end-user knows how to. This is a rather obscure and dying art; one does not rely on end-users to have mastery of it. In these times, end-users expect software to "just work".

: > d. Offer only an incomplete and sketchy model of any real terminal,
: > not even close to sufficient for defining an accurate emulation;
:
: My vt100 emulator, which used raw termlib, did a better job of vt100
: emulation than most commercial packages. It didn't try and provide
: perfect visuals: double-wide and double-high letters, for example, were
: simply not addressed. But it passed the vt100 torture test.
:

Then it didn't run strictly from termcap/terminfo information; otherwise, it wouldn't have been a vt100 emulator, it would have been an emulator of every terminal that had an entry in the database, right? The database only encodes certain information about a terminal, not all the information needed to make a fully functional emulator. Such items as report requests and responses, forms-filling, and blockmode spring to mind.

: > e. Notorious for refusing to work due to library version mismatches;
: > f. Sometimes not available at all.
:
: That's an easy fix. Same solution as B.
:

It's easy if you understand cryptic messages about shared libraries, and are familiar with the politics regarding curses vs ncurses, libc vs glibc, competing numbering schemes, etc, and what to do about them.

: >And that in any case, this does not solve the original problem:
: >
: > How do I map Shift-Alt-F7 to such-and-such a function?
: >
: >The answer will still be: "you can't, because the software has no way of
: >knowing that you pressed Shift-Alt-F7".
:
: With a keyboard mapping file that maps escape sequences to symbols that
: the user's interested in.
:

If xmodmap recognizes your keyboard and can see Shift-Alt-F7 as distinct from other key combinations, then yes, but only for xterm. A separate solution is required for the console. Remote (non-X) sessions haven't a prayer.

You win some and lose some. UNIX is a general-purpose multiuser operating system designed originally to be accessed from a terminal, and in fact a variety of terminals. The idea of a UNIX workstation with its own keyboard and screen was grafted on later and is still not a good fit.

DOS and Windows, on the other hand, are single-user operating systems designed to be used ONLY from the built-in keyboard, mouse, and screen, and therefore include APIs (or direct hardware access) that make terminal emulation possible in the sense that most people expect. But this is at the expense of generalized accessibility.

It is hard to explain this to people who expect UNIX to be like Windows. While it might be possible to write a true terminal emulator for a specific UNIX variety on specific hardware that runs only in an X window (and in fact there are numerous examples -- xterm, Xfree86 xterm, the xterm versions from HP, IBM, and other companies that emulate their own proprietary terminal types), it is not possible in the general case, due to differences in hardware (e.g. different keyboards), windowing systems (in the X environment), screen drivers (in the console environment), APIs, and access methods.

• Frank