Porting DOS Applications to Linux

 in
Trying to port a DOS application to Linux? Alan Cox gives you hints and practical help.
Where is the foo() Function?

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.

Executing Other Programs

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.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Error in listing 2

Graeme's picture

The second call to signal in term_ctrlz should be a call to kill, i.e. kill( getpid(), SIGSTOP );

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState