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

In article <7johsh$egs$1_at_newsmaster.cc.columbia.edu>, Frank da Cruz <fdc_at_watsun.cc.columbia.edu> wrote:
>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().

Luckily you don't need to account for it by writing 12 versions of the code. I normally encapsulate tputs itself into a routine (the name I usually use is "outs"), and since C specifies that (char) promotes to (int) in fuction call and return, that leaves you with two versions of the call to tputs and two versions of the output function, in one place in the code.

>: > 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".

End users who aren't using ANSI X3.64 compatible terminals in 1999 are already at the extreme end of the envelope.

>: > 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?

No, it was a vt100 emulator that emulated the vt100 on every terminal in the database.

> 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.

Luckily I haven't ever had to deal with that on a vt100. Virtually all the software I've ever run into that used block mode used it on a Televideo, a Televideo-compatible, or a Uniscope.

But there's nothing inherently more difficult about dealing with block mode than dealing with any of the other behaviour termcap doesn't specify.

>: > 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.

I haven't run into that, but then I haven't writen code for Linux.

>: >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.

Where did I say anything about xmodmap? I'm simply saying that a properly written terminal emulator can run on UNIX and provide the functionality required. That there isn't one that you know of is because there isn't a great need for one, not that one's hard to write. As I said, I wrote one that ran on Xenix-286, Solaris, and System V back in the late '80s. It was a port from a DOS program I'd previously written, and I didn't find the porting particularly difficult. Certainly dealing with termcap was a lot less hassle than dealing with PC serial ports.

>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.

That's just plain not true. Curses provides all the functionality you need to write one that is portable to multiple UNIX systems and runs under multiple terminal types. Yes, you do need to write your own keyboard mapping code, but then you already have to do that to write a terminal emulator under Windows that runs on internationalized versions.

I've done it myself, and there were several companies back in the '80s who had commercial products that ran on a wide variety of UNIX platforms... I used to have half a dozen boxes back in the computer room but they seem to have been flushed in one of the spring cleanings. You can do as good a job of vt100 emulation on a UNIX system as you can on a PC.

--
In hoc signo hack, Peter da Silva <peter_at_baileynm.com>  `-_-' Ar rug tú barróg ar do mhactíre inniu?   'U` "Be vewy vewy quiet...I'm hunting Jedi." -- Darth Fudd Received on Fri Jun 11 1999 - 08:27:33 CDT