@(#) PORTING 2.1 90/01/22 13:01:09

This document gives some hints to people who might consider to port the
programs to an environment different from UNIX or MS-DOS.  Fortunately,
the programs themselves are written in portable (old-style) C. The only
exception is the MS-DOS serial port driver, which isn't portable at all.

First of all, search the source files for #ifdef constructs.  This
should give an idea where the system-dependencies lurk.

The main problem will be serial-port I/O.  If possible, try to build on
top of what the GNUUCP people have already done in this field.

A less severe problem should be console input/output.  The programs do
not use any graphics at all, nor are special input devices such as mice
required.  If your machine provides some kind of vt52 or vt100
emulation, adapt the console.c and tgoto.c files in the termcap
subdirectory.  On machines without some form of text window on the
console, porting will require too much work.  Most keyboards generate
codes that can be easily encoded in the console.c file in the termcap
subdirectory.  Most C compilers provide some form of "raw" keyboard i/o
that does not require the user to press ENTER, and that produces no
echo.  You may wish to consult a UNIX programmer's manual to find out
what the two-letter codes in console.c are all about.

Process management may need some attention.  The programs were written
in the UNIX style, i.e. many small programs dedicated to a single task.
Programs invoke other programs.  Each program returns an exit status,
such that the parent program can take appropriate action if things went
wrong.  If your operating system does not provide facilities to invoke,
from with a program, other programs with command-line arguments, you
lose.  Sometimes, programs can only be invoked with the "aid" of a
command-language interpreter.  This often causes the exit status of
programs to be lost; the net result will be less reliable operation of
the pc-mail software.  In the case of MS-DOS I compromised:  batch
command files must be given including their suffix, so that special
arrangements can be made; other programs are invoked directly without
intervention of a command interpreter.

File i/o should be taken care of by your C library; make sure that
"text" and "binary" modes are used at the appropriate places.  Just look
up where O_BINARY appears in the source.  If your C library does not
need to distinguish between text and binary file i/o, you are lucky.

You will have to provide some form of the Berkeley-UNIX directory
library routines; they allow any program to scan directories for the
names of files.  By now, these routines should be publicly available for
most reasonable operating systems.  Make sure that the version you use
produces file names in lower case (or take appropriate measures), and
that it behaves well even in the root directory of a file system
(MS-DOS doesn't, so I had to compromise again).
