Porting DOS Applications to Linux

This is commonly asked of a specific set of DOS C library and system functions, most notably the various text mode window packages, kbhit(), getch(), getche(), and the string functions stricmp() and strnicmp().

Not surprisingly, equivalent functionality exists under Linux. The text mode window case warrants a section of its own, so you will have to wait a minute or skip on ahead. The string functions are nice and easy. stricmp() is also known as strcasecmp() and strnicmp() as strncasecmp()---there is just a naming difference.

The keyboard I/O routines cause problems because Unix terminal I/O is a lot more flexible than DOS terminal I/O, and in the case of kbhit() it does not suit the multitasking nature of the system to have the CPU spend all its time in loops polling the keyboard. Furthermore, unlike in DOS, the terminal mode is set explicitly, rather implicitly by each call. A set of routines (the standard POSIX termios functions) exist to manipulate the control structures for each device.

You cannot use the various privileged instructions that might otherwise harm the machine integrity. Controlling I/O devices is done by devices in the kernel, with access through file abstraction (the “special” files in /dev/), rather than directly. It is possible (but dangerous) to use ioperm() to allow access to devices in a process running as root if absolutely necessary. Any code that does this will be non-portable, and thus this should be used for special purposes only. mmap() can be used for equivalent access to the device memory window on a PC (640KB-1MB), but this is equally as bad an idea for normal use. In particular, you should never, ever, attempt to do screen output this way.

The Linux environment is built on the basis of small, effective, programs working together. Therefore, there are a wide variety of program execution facilities. They differ from the DOS environment in very specific ways. There are no equivalents to the various “swap out existing program and spawn another task” facilities found under DOS. The Linux virtual memory system will automatically decide by itself what to swap out and when. Secondly, the basic constructs of Linux process execution have no equivalents in DOS, even though there are library routines which do.

The simplest way to run another process is via the system() function, which calls a shell and feeds it a command string for interpretation and execution. All of the normal shell parsing and redirection is performed. This means that you should be careful of the arguments you pass if you don't want the shell to misinterpret any special characters.

This is a simple example of a program that shows who is logged on, and then who is logged on to the remote machine called “thrudd”.

void main(int argc, char *argv[])
{
  system("who");
  system("rsh thrudd who");
}

The Linux system makes heavy use of pipes—a way of feeding the output of one command into another. This is not just a shell facility. Any program can read or write from another using the popen() and pclose() calls. These work the same way as fopen() and fclose() do, save that popen() is passed a program as its argument. Because pclose() handles the termination of the process created by popen(), it is important to use the right close routine.

This brings us conveniently back to printing for our next example. Here is a set of subroutines for printing a file:

FILE *open_printer(char *printername)
{
  char buf[256];
  sprintf(buf,"lpr -P%s",printername);
  return popen(buf,"w");
}
void print_line(FILE *printer, char *line)
{
  fprintf(printer,"%s\n",line);
}
void close_printer(FILE *printer)
{
  pclose(printer);
}

Unlike DOS, Linux has no support for overlays in the linker, nor for loading overlays in the C libraries. The memory management and virtual memory system will swap unused program segments out of memory without assistance from the program being swapped and will automatically bring them back in when they are needed. Using overlays would not speed up program startup time, either. Program code is read from disk whenever the page of code in question is needed and not found resident in memory. The new ELF library format does support dynamic linking, and you could conceivably implement overlays using it. This is, however, pointless.

The core routines Linux provides for process execution are execve(), fork(), and wait(). The execve() call replaces the running program image with another one. The original is destroyed totally. The fork() call creates a new copy of the existing process. The only difference between the copies is the value returned by fork() (the process id of the new process in the parent, 0 in the child). Finally, the wait() call lets you wait for a process to complete. This level of control is unlikely to be needed when porting DOS programs, so they are not covered here.