Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.misc -> Re: ISO VT320 emulator with key-bindings for Oracle Forms

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

From: Scott G. Hall <Scott.Hall_at_GSC.GTE.Com>
Date: Tue, 8 Jun 1999 19:31:35 GMT
Message-ID: <375D6F97.9054BBCB@GSC.GTE.Com>


Frank da Cruz wrote:
>
> Scott G. Hall <Scott.Hall_at_GSC.GTE.Com> wrote:
> : "Richard S. Shuford" wrote:
> : >
> : > "Frampton Steve R" wrote:
> : > > I'm in need of a VT320 emulator with key-bindings for Oracle
> : > > SQL*Forms; it needs to either run under Linux/Unix or [in dosemu].
> : >
> : > Keep in mind that character-cell terminals communicate their
> : > keystrokes by means of Escape sequences, as opposed to scan codes.
> :
> : There is another regular poster to this newsgroup who is the author of
> : Kermit-95. I believe that he emulates the VT-220 function keys correctly
> : so that it would work for you. Let's hope he is reading this now, and
> : can reply if he has a version for UNIX.
> :
> Sorry, we can't make terminal emulators for UNIX as we do for DOS and Windows,
> since in UNIX we do not have direct access to the keyboard and screen. How
> is a UNIX application supposed to know that you pushed F7 on your keyboard,
> or Ctrl-F8, or Alt-Right-Arrow, etc? It usually doesn't even know what
> kind of keyboard you have.

Standard terminfo stuff. The program "cu" in the UUCP package is an example of a terminal emulator for UNIX, but one that does no remapping. It sets the port in "raw" mode and reads the character from the terminal directly, and just sends them on to the remote application.

A remapping terminal emulator would act just like cu, but when it gets the characters from the terminal, if it receives the "Esc" character (or whatever escape code defined by its term type in the terminfo capabilities database) it checks for what capability the next several characters match. Then it sends the equivalent escape sequence to the remote application that matches the same capability for the terminal being emulated.

Say for instance that you are working from a Sun console keyboard (term type "sun"), and you want to emulate a VT-220 for a specific application. When the user would press the F6 key, the sun term type sends to your emulator the escape sequence: \E [ 2 2 9 z The terminfo capability for this keystroke is "kf6" or "the F6 key" for the sun term type. The emulator program would then output to the remote application the escape sequence: \E [ 1 7 ~ , which is the terminfo capability "kf6" for a vt220 term type.

Same thing for escape codes read from the remote application. If a match is made for a capability being emulated, then the emulator sends proper matching capability to the user's terminal.

This can be made independent easily by using the standard UNIX curses library. The library has calls for reading keystrokes and telling you what key was pressed. The library also has calls for sending to the user's terminal the correct output codes, just by called the standard curses functions. So the emulator only needs to concern itself with the escape codes that it is emulating, and leaves the escape code resolution for the user's terminal screen and keyboard to the curses library. In this way the user can move from a Sun console to a Regent-60 without the emulator knowing or caring.

> Remember that UNIX, unlike Windows and friends, can be accessed:
>
> 1. From the raw console (the workstation's physical keyboard and screen
> without any kind of window manager);
> 2. From an X window, using the workstations real keyboard and screen;
> 3. From an X window, but on some other computer;
> 4. From a Telnet session (or Rlogin, etc);
> 5. Through a serial port.

I think you misunderstand how UNIX works. UNIX programs cannot access the above directly, but rather access the user's terminal device node (the special file for the terminal in the /dev/ hierarchy). This is not limited to serial devices, but any terminal device (a TCP port & its pseudo port, or pty, a parallel port terminal, or others).

> A terminal emulator might be possible in case (1), but there would need
> to be a different one for every UNIX variety on every kind of hardware,
> so it's not likely to happen.

Nope. The program uses curses to access the user's terminal, and this becomes fully portable from terminal type to terminal type and port to port. Easily done. In fact, I think there are commercial products for several years doing just this.

>
> A terminal emulator is possible in case (2), but you already have one. It's
> called xterm. The regular xterm emulates vt100, and there is a vt220 version
> available at:
>
> http://www.clark.net/pub/dickey/xterm/xterm.faq.html
>
> Start xterm and then run Kermit in the xterm window and poof: you have a
> terminal emulator that can make serial or network connections to other
> computers. Key mapping is handled by xterm.

And I have one that emulates a Wyse-60 w/Function keys, and Prime P-100 terminal, and a different one that emulates a Regent-60 w/Function keys.

--
Scott G. Hall
GTE Government Systems
North Carolina Systems Center
email: Scott.Hall_at_GSC.GTE.Com Received on Tue Jun 08 1999 - 14:31:35 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US