Lan Barnes is a microcomputer systems programmer and database consultant working in MS-DOS and QNX. He has written a full-screen QNX editor that he is converting to QNX Windows in his spare time. Readers may contact him at 822 Guilford Ave., Suite 147, Baltimore, MD 21202.
In recent years the QNX operating system has become a favorite of systems designers. QNX is a networked OS (or NOS) for microcomputers capable of combining real-time performance with a user interface that can support "friendly" applications. The system has been around for awhile — Quantum Software Systems, QNX's vendor, has been shipping one form or another for ten years. Nevertheless, QNX is less dated than many younger operating systems. Its underlying modular, message-passing architecture still stands as a fresh and powerful alternative to conventional OS and NOS designs.
The friendliness of QNX's user interface, however, can be challenged. The traditional QNX shell interface can best be described as "UNIX without the frills." While programmers and network administrators tend to appreciate QNX's spare elegance, new QNX users — even the more technical users typical of a real-time environment — have always been subjected to a steep learning curve. In today's micro culture of graphical user interfaces, QNX developers felt an obvious need for a GUI for QNX.
Such a GUI was announced and released at the QNX Developers Conference in Ottawa last fall. I provide here a high-level overview of that GUI, called QNX Windows.
Open Look Standard
QNX Windows is based on the Open Look standard supported by, among others, AT&T and Sun Microsystems. Open Look is a pleasing standard, depending heavily on familiar visual references to provide intuitive ease of use. For example, you scroll by using a slide bar. You make both exclusive and nonexclusive choices using buttons that invert in shadowing when you toggle them, so they appear depressed.
Small, standardized icons provide features in an intuitive manner. Menus can be made "sticky," for example, so that they will remain in view after a selection, by clicking on an icon of a pushpin in the menu's corner. Similarly, a selection that leads to a submenu has a wedge-shaped arrowhead beside it, while a terminal selection does not.
Open Look's ease of operation does not come at the expense of control subtlety. Consider the example of the ubiquitous slide bar. This icon, which looks and acts like a stereo control, can interpret a single mouse click to scroll:
- to the beginning
- to the end
- up a page
- down a page
- up a percent of the total
- down a percent of the total
Necessary Resources
I confess that I found Open Look as expressed in QNX Windows to be easy and intuitive to pick up. For me, this a profound concession, since I have been described as a "mouse-hostile anti- windows curmudgeon" by my GUI-enthusiast friends. But the proof of a GUI is in the programming. More specifically, a GUI's real value is a function of the performance it provides compared with the resources it consumes, including that most valuable resource, programmer's time.
In hardware resources, QNX Windows requires a minimum of an 80286 machine with 2 MB of memory and either EGA or VGA. Unlike other GUIs, this minimum requirement is realistic, and gives satisfactory performance. I tested the package on my home machine, a 286 that cruises along at a sedate 9.5 mHz with one wait state and hard drive seek times in the mid-50s (counting in msec.). This combination performed quick screen painting and smooth scrolling, even with a background process running.
Quantum claims that QNX Windows will outperform such GUIs as Open Desktop on machines with half the clock speed and a quarter of the memory. I can't refute that. I know, by comparison, that Microsoft Windows 286 limps along on my machine to the point of being less than useful.
Programming Interface
For a C programmer, any new system must be judged in terms of its function library and the programmer's model that lies behind it. The Open Look programmer's model begins with the definitions of page, pane, and window, the logical elements from which a QNX Windows application is built.
To build an application in QNX Windows, the programmer starts by defining a "page." At the lowest level, a page represents a buffer in memory into which the program builds objects that will display on the page. Each page may have from one to four "panes," which may be thought of as subwindows. Panes serve as natural subgroupings for elements on the window's picture. Tying these together is the visible "window," which may be thought of as a view into the page beneath it.
QNX Windows is strongly object-oriented. Every element that may be put on a page represents a highly smart object. For example, objects such as buttons or menu selections remember their color, shape, and location. They also remember whether they highlight or change colors when selected.
In fact, a QNX Windows object knows everything about its screen display. QNX Windows handles that display without needing direction from the programmer's application. Thus, if you click on a button, it will automatically perform whatever its visual task is — become depressed, change color, or pick up a check mark, for example. The button will also send a message to the application that it has been selected.
The underlying protocol that makes all this possible is client/server. The QNX Windows process runs on the display node as a windows server. (It must have a graphics terminal.). Client processes queue requests for windows services. This design husbands resources at the same time that it enhances performance. Only one instance of the windows code is necessary per display node, and the display is always painted by the local processor, even if the requesting process is running on a distant node.
Performance can be further enhanced if applications programmers follow a "draw first, then show" discipline. Changes to the window should be written into the picture buffer with draw function calls until the new window is complete. Then the changes for the completed window are sent to the screen. This gives a pleasing, instantaneous effect on the video display.
The Function Library
QNX Windows' function library, the other half of its API, comprises approximately 200 function calls divided into 20 functional groups. These range from low-level functions that draw arcs, points, Bezier curves, and the like, to high-level calls that draw complete menus, meters, or slidebars in a single function call.
The authors of the library avoided chaos by following a rational naming convention very much along modern C lines. Each function name begins with a functional-group word, such as Draw, Picture, Set, or Event. Following that is the name of the target object or action, as in DrawButton, PictureOpen, SetColor, or EventWaiting. As with all good naming conventions, the programmer is able to predict the name and existence of a function very soon after starting to use QNX Windows. I have put aside my grumbling about the "creeping Pascalization" of C, and have oiled my rusty shift key.
Object Orientation
Using the QNX Windows library is facilitated by the design paradigm that all screen constructs, such as buttons or menus, are high level objects that store a complete set of characteristics for that object. Each windows process has a context — a set of color, fill, and line defaults that will apply to each draw operation as it occurs. These characteristics are copied through to the drawn object, thus fixing its characteristics even if the context is changed later.
Each object, be it a menu or dialog box, has an optional "tag," a string identifier of up to 255 characters that may be used as a handle in subsequent manipulations of that object. Although objects can also be located by their type or their coordinates on the picture, the use of tags goes a long way toward preserving the sanity of the QNX Windows programmer.
High-Level Objects
Because the Open Look standard defines a continuum of user interfaces, the designers of QNX Windows had the opportunity to develop many complex objects, such as menus and dialogs, into single function calls. That opportunity was not neglected.
Menus are a special case of dialogs. Menus follow the Open Look conventions of having a wedge shaped submenu mark and being selectable through the right mouse button. You can display a menu by calling the function Menu, which needs only five arguments:
- a label
- a title
- the number of display columns
- a list of menu items separated by semicolons
- a string of option characters
A program frequently needs file-selection menus. A second function call, FileMenu, creates a menu with two special arguments — a directory and a wild-card skeleton. The menu can present files of a specific type from a specific directory. Both arguments are string pointers, so the application can put the directory and skeleton under user control.
Another standardized QNX Windows dialog is a "notice." A notice displays a message such as "Printer has jammed," with a clear button labeled "OK" (as if a jammed printer is ever OK). A help text system allows contextual help to be stored in simple text files and called up by an interactive browser. These help text files are all stored in a common directory. An application could even allow a user to modify the program's help text.
QNX is so closely associated with the world of mission-critical and real-time systems. It is heartening to see that the QNX Windows library provides two functions called DrawNumber and DrawReal. These present numerical data to screen objects in a variety of formats, including dials, meters, bars, and gauges with or without sliders, end buttons, and ticks. It is a tribute to the server approach that these formidable coding chores can be reduced to function calls each with five parameters. They can also be present for all processes with a single instance of code in the server.
Programming Paradigm
A QNX Windows application does surprisingly little setup code to get the system rolling. Listing 1 shows the code necessary to produce a "Hello world" message box. This illustrates the underlying "draw, then show" philosophy in QNX Windows. The first three lines set up the picture in memory. The fourth line uses the picture tag test to show the picture in a window. Line five replaces the standard QNX call to receive. As a message passing OS, QNX is geared to using asynchronous, event-driven algorithms. No QNX code fragment would be complete without some line that waits on a message (or sends one).
The code in Listing 1 cannot discriminate among messages. That is acceptable perhaps if we simply want to clear the "Hello world" after any mouse click. Usually, however, a piece of QNX Windows code will have an event loop similar to the one in Listing 2.
Listing 3 is the complete code for a puzzle game shipped with QNX Windows. The puzzle is familiar to most of us as a small flat box of numbered tiles that can be slid past each other. The box has 15 tiles in a 4 X 4 enclosure, leaving one space for maneuvering the tiles. I don't like these puzzles, probably because I'm not any good at solving them, but I do note that the source for this windows application has only 300 lines of C code.
Summary
The QNX Windows GUI combines the features of both a high-level and low-level C windowing library with a client/server window driver design. The resulting GUI provides a powerful development environmen. It does not sacrifice the performance that has made QNX a favorite OS among those involved in mission-critical or real-time software.
The QNX Windows developers toolkit can, I suspect, speed application development for current QNX users. Perhaps its handsome presentation, following the Open Look standard, will lure new QNX users into the fold.
Figure 1
