[comp.software-eng] Question about portability issues

art@dinorah.wustl.edu (Arthur B. Smith) (12/08/89)

Greetings netlanders!

    Pardon the extreme cross posting!  We are working on a large
software project (ca. 20+ person-years).  It has been developed thus
far in C to run on a DECstation 3100 running Ultrix (BSD derived)
using X11R3 (but not DECwindows).  It is a multi-process system, with

    It has become apparent that we will need to have this system
running on a Silicon Graphics 4d series box running IRIX (System V
derived), and a scaled down version of this system on some 80386 or
80486 based "PC" running Xenix or some other *ix. These will probably
all be developed in parallel (common source, using #ifdef's and the
like where necessary). 

    Unfortunately, all of us are raw novices at this cross-system
portability issue, and we collectively have very little experience on
non-BSD derived Unixen.

    What I am looking for, therefore, is any wisdom on what is going
to be necessary.  I am looking for any of:

    * How much more time (than just developing under Ultrix) will this
      take? 

    * Should some people develop and others port, or should we all
      learn to write portable code by porting what we write.

    * Any recommendations for a 386/486 box and/or operating system?

    * Any major pitfalls to avoid?  If we can learn from other's
      mistakes, that would be wonderful!

    * Any problems with using BSD sockets?  X Windows?  File system
      issues?  Something else?

    * Any techniques that you have found helpful in doing this type of
      thing?

    Please respond by e-mail to art@dinorah.wustl.edu or
...!uunet!wucs1!dinorah!art (I can't possibly find time to follow ALL
these groups! 8^).  If you are interested in a summary of the
responses, please indicate that, and what newsgroup you would like to
see it in if there are a lot of requests.  I will summarize in one
form or another to all who ask.

    	 Thanks in advance!
    	    -art smith
(art@dinorah.wustl.edu   or   ...!uunet!wucs1!dinorah!art)

Most of the words in the first three paragraphs are somebody's
trademark.  

Usual disclaimers apply.

bd@hp-ses.SDE.HP.COM (Bob Desinger) (12/09/89)

[I replied by mail, too.]

>   * How much more time (than just developing under Ultrix) will this
>     take?

This greatly depends on your people.  I used to work for a porting lab
and the human factors were the ones that caused the most variance.
Nearly any task turned out to be easy if you could automate it.
Anything that required a human to do manually was time-consuming.

>   * Should some people develop and others port, or should we all
>     learn to write portable code by porting what we write.

Start small and write the absolutely-necessary core functionality.
Then have the writers port that themselves.  They will learn by doing
and the rest of the program will be much more portable.

>   * Any major pitfalls to avoid?  If we can learn from other's
>     mistakes, that would be wonderful!

A good technical bookstore should have a few books.  J. E. Lapin (a
pseudonym for Rabbit Software) wrote a great reference book on
portability.  Mark Horton wrote one more recently that I haven't seen
yet.

>   * Any problems with using BSD sockets?  X Windows?  File system
>     issues?  Something else?

Some file systems impose a limit on filename length; this hurts
because you have to change #include file names and Makefiles, although
you can speed the process up with a combination of shell scripts and
the `overwrite' program from _The_Unix_Programming_Environment_ by
Kernighan and Pike.  I don't know if SGI has this problem; I suspect
not because most Unixes these days allow long file names.

>   * Any techniques that you have found helpful in doing this type of
>     thing?

Besides reading the (few) books on portability, I've benefitted in
the long run by studying and porting public-domain sources that run
on several machines.  The MH system, GNU software, the netnews
distribution, and anything written by Larry Wall (like Perl) would be
good starters.  You can get insights from their #ifdefs even if there
aren't many comments, even though it's hard work to look at it all.

A good debugger is worth its weight in gold.

Hope this helps,
bob desinger