Practical C Programming, 3rd Edition

Chapter 20. Portability Problems

Wherein I spake of most disastrous changes,

Of moving accidents by flood and field,

Of hair-breath ’scapes i’ the imminent deadly breath...

—Shakespeare, on program porting [Othello, Act 1, Scene III]

You’ve just completed work on your great masterpiece, a ray-tracing program that renders complex three-dimensional shaded graphics on a Cray supercomputer using 300MB of memory and 50GB of disk space. What do you do when someone comes in and asks you to port this program to an IBM PC with 640K of memory and 100MB of disk space? Killing him is out; not only is it illegal, but it is considered unprofessional. Your only choice is to whimper and start the port. During this process, you will find that your nice, working program exhibits all sorts of strange and mysterious problems.

C programs are supposed to be portable; however, C contains many machine-dependent features. Also, because of the vast difference between UNIX and MS-DOS/Windows, system deficiencies can frequently cause portability problems with many programs.

This chapter discusses some of the problems associated with writing truly portable programs as well as some of the traps you might encounter.

Modularity

One of the tricks to writing portable programs is to put all the nonportable code into a separate module. For example, screen handling differs greatly on MS-DOS/Windows and UNIX. To design a portable program, you’d have to write machine-specific modules that update the screen.

For example, the ...