HTML HMI Software Upgrade

to

VT-100 Terminal Applications

by

William H. Bytheway

November 22, 1998

Background

There are many software applications written for the VT-100 terminal as a Human Machine Interface (HMI) that still have some usefulness today. Since technology has evolved from the basic 80x25 text-only display to Graphical User Interfaces (GUI), the thought occurred that there must be a way to migrate these VT-100 to VT-420 based applications into GUI with minimal effort.

Purpose

The purpose of this white paper is to introduce the concept for upgrading existing VT-100 based software applications with a new GUI interface at minimal cost, complexity and risk. Changes to the GUI interface must be easy and quick to implement to meet changing user needs.

This white paper introduces the concept of using Hypertext Markup Language (HTML) and popular WEB based browsers as a means of replacing text-only displays with a GUI.

Selection of Candidate Software

In order to demonstrate the concept, a simple VT-100 application needed to be selected for the prototype. Source code had to be available for the target development platform.

A simple mail user interface called Basic Mailer (BM) for the KA9Q TCP/IP package was chosen as an example of a text based application designed to run on a VT-100 terminal. It was originally written by A.D. Barksdale Garbee II and Dave Trulli who released the source into the public domain in 1988 and granted permission for non-commercial copying and use. This software ran in a DOS shell outside of the KA9Q TCP/IP package and accessed the KA9Q mail directory structure.

The BM application runs in conjunction with the KA9Q TCP/IP software written by Phil Karn that runs in MS DOS and provides the basic Simple Mail Transport Protocol (SMTP) and Post Office Protocol (POP3) interfaces to the TCP/IP network. This software and BM were chosen to work together to provide a software development and test environment.

Development Environment

The development machine is running Microsoft Windows 3.11 on a 80386-25 with TCP/IP packet drivers installed. Ethernet provides connectivity to a second machine running Windows95 on a Pentium and contains a recent copy of Netscape Navigator and Internet Explorer WEB Browsers. Software is developed using the Borland C++ 4.0 Integrated Development Environment, and the target executable is a Windows 3.1 application. TCP/IP WINSOCK drivers and libraries were obtained from the Borland FTP site.

Windows Based WEB Server

The first step would be to build a basic WEB server that responded to basic Hypertext Transfer Protocol (HTTP) GET command. This was already accomplished in an earlier development effort to build a standard software interface for TCP/IP servers and clients. The module called “TCPIP.C” was written to support Borland C++ version 4.0, other versions were created to support Microsoft C++ version 7.0 and Borland Pascal version 7.0.

The prototype WEB server written in C was built as a Windows 3.1 application. It runs on top of the Microsoft WINSOCK TCP/IP layers and supports only one socket at a time. The basic HTTP GET command returns the file requested in the command argument . Added to the server was an HTTP ISINDEX search engine that would perform a string search in a text file and return all matches.

The second step was to develop a software module that would interface between BM text I/O and a TCP/IP socket. This would be used for reading the keyboard and sending data to the display. BM used standard ANSI C language functions for this, so a software module called “XPRINTF.C” provided basic function replacements for each I/O occurrence. It was decided that while redefining the standard ANSI C functions could be done, that it was easier to create a new function “xprintf” and then reformat the data on a case-by-case basis.

The final prototype product is called WIN_HTTP, an HTTP server built around a VT-100 terminal E-Mail application. It runs on Microsoft Windows 3.1 on top of WINSOCK and provides not only basic HTTP support for GETs, but also allows the user to list and read E-Mail bulletins that show up on the main computer.

HTTP Interface Protocol

A very simple method was used in defining the interface protocol between the WEB browser and the server. A single letter ‘N” followed by options told the server that the incoming GET request was to be directed to the BM E-Mail software modules. As shown in Figure 1, subject areas that reside on the host computer are displayed as hypertext links.

Figure 1: Message Area Selection Menu

Selecting one of the areas then brought up a listing of the mail in that area. Each item was a hypertext link to the particular message as shown in Figure 2. The original BM print format was retained without modification, since it showed message details the user would be interested in.

Figure 2: Message Selection List

Software Complexity

Adding to HTML wrappers around the BM I/O functions was not too difficult to do. The basic code for adding this to the software looks similar to the following structure that defines a header and a footer wrapper around the text.

<HTML><BODY><PRE>

<<<<< Text Message Body goes here >>>>>

</PRE></BODY></HTML>

The HTML <PRE> command insures that the text will be treated as a fixed-width font, so that spaces and tabs will be retained as closely to the original VT-100 output as possible.

In some cases, the I/O data format had to be modified to match the “xprintf” function, this was done using the “sprintf” as shown in the following example.

sprintf(temp,"Message #%d %s\n", msg,

mbox[msg].status & DELETE ? "[Deleted]" : "");

xprintf(socket,temp);

Point and Click HMI

In the examples shown above, very simple HTML commands were used to create the user interface additions to the VT-100 application. By adding HTML FRAMES, the user could provide a point and click interface to any command. The brains of the operator scripts and procedures would be contained in the WEB based file, and the interface to the application would HTML via TCP/IP sockets. In the following example, a WEB interface was created in the KA9Q TCP/IP application which interfaced to the system management functions. For example, a command to list the current RIP STATUS settings would show up as a simple menu item or button on the display. The operator would only need to click on the function as shown in the following example:

Figure 3: Using Tables and FRAMES to Simplify Interface

As you can see in Figure 3, the top part of the window uses tables to divide the functional areas of the interface and has it’s own scroll bars, the bottom window is used to display the results of the request and has it’s own scroll bars. This makes it fairly easy for the operator to select only the function they want with the mouse.

Where FRAMES would be used would be to emulate the windowing of display areas on VT-100 displays. Multiple windows using frames can be defined to divide data up into specific areas. The example above showed two such windows.

Adding a little JAVA in-line code to each of the functions, scripts can now be built that would guide the user through the steps of a procedure in sequential order, keyboard errors would be eliminated. Changes to the script would only require a simple text editor to the HTML file and not the application code. Unique GUI interfaces could be built for a multitude of different applications or users.

To even more increase the capability, JAVA applets, which are pre-compiled executable code, can be created to even further streamline the user interface and add capability. The executable code is loaded on the user’s workstation using the HTTP GET command.

Since a standard WEB server is not being accessed, CGI and PEARL scripts cannot easily be used with this type of interface. This type of code executes on the server, and since the WIN_HTTP server is a basic HTML front end to a VT-100 interface, adding it would not be practical.

Summary

This prototype demonstrates that modifying a VT-100 based application with an HTML GUI HMI can be done with minimal effort and cost. The example pictures in this white paper used a popular WEB browser that is supported by UNIX, OS2, Windows95 and Windows 3.x operating systems. The HTML standard makes it easy to transition from one OS to another without rewriting the GUI interface.

The amount of time spent on making the modifications to the BM code took less than a week of evenings to develop and test. Most of the time was spent trying to overcome the short-comings of Windows WINSOCK to make the front end relatively bullet proof. Now that the “TCPIP.C” module has been tested and debugged, it can be reused in other applications.

Complexity of performing the changes was minimal compared to creating a MOTIF, Windows or Xwindows GUI. Cross-platform compatibility is no longer a problem, and GUI changes can be made without recompiling the source code. A simple text editor can be used.

This white paper has shown that it is practical to add a GUI front end using HTML to an existing VT-100 user interface and breathe new life into an old application. It’s hoped that this method can be used on future proposals to upgrade existing VT-100 terminal software.