Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!hp-ses!bd
From: bd@hp-ses.SDE.HP.COM (Bob Desinger)
Newsgroups: comp.software-eng
Subject: Re: Question about portability issues
Message-ID: <6100002@hp-ses.SDE.HP.COM>
Date: 9 Dec 89 00:31:03 GMT
References: <1051@dinorah.wustl.edu>
Organization: HP Software Engineering Systems, Palo Alto
Lines: 49

[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