Porting DOS Applications to Linux

Until recently there was no standard control API for mice in text mode (in graphics mode X-Windows runs the mouse and provides all the facilities you would imagine a GUI to have). The normal mouse behaviour is to provide text mode cut and paste. This is managed by a program known as selection and more recently by gpm.

The gpm library allows your text mode application to handle mouse events both on the console and under X-Windows in xterm shell windows. Writing programs that use gpm to control the mouse is explained in article “Writing a Mouse-Sensitive Application” issue 17, September, 1995.

Occasionally you will have to port a DOS terminate-and-stay-resident (TSR) program. If you have been accustomed to using undocumented DOS calls and switching stacks and other horrible assembly language goings-on you will be glad to know you can forget the experience.

First, the whole concept of terminate and stay resident is gone. When a program exits all its resources are freed, and the process ceases to exist. That does not mean the same facilities are not present; they are present in different ways that are more appropriate to a system which is already multitasking.

There are three main reasons for TSR programs under DOS.

For the second example, some TSR programs can be ported as if they were applications that provided services. The gpm mouse management is a fine example of this. It provides the core equivalents of the DOS mouse services interrupt facilities as an application program that runs in the background and a library of support routines which interface with the server.

Graphical programs are much more complex to port, because the graphics hardware interface is not available. You can approach this two ways. First, svgalib provides the basic functions you need to port your application. Note that you cannot use the BIOS functions, because they are only available in 16bit mode. An svgalib application can be very fast (see linuxsdoom for a superb example), but cannot run remotely and is not easily ported beyond PC-based systems.

The second approach is to use X-Windows. This makes for a much harder port, as you will need to move to an event-based paradigm (akin to programming for MS Windows) and rewrite your interface dialog and menus into X widgets. Furthermore X-Windows programming is—initially at least—quite hard to get the hang of. The result, however, is a graphical program that is portable and can run remotely. X-Windows is generally slower than raw SVGA, as one might expect. There is, however, an extension (called Xshm) that Linux and most Unix systems include, which supports fast bitmap updating as occurs commonly in games.

In the “cheat box” there is also Tcl/Tk, a front end language for writing easy X-Windows interfaces. Its applicability to a given program is very hard to summarise. However, applications that are basically modal can generally make best use of Tcl/Tk. Using Tcl/Tk to write front ends for programs is covered in “Using Tcl and Tk from Your C Programs”, Linux Journal issue 10, February, 1995.