art@dinorah.wustl.edu (Arthur B. Smith) (01/16/90)
Re-greetings, netlanders!
Many thanks for all the responses to my posting about portability.
All in all I got more than 50 pages (not counting the source to conf)
of responses ranging (as expected) from the ridiculous to the sublime.
I will try to summarize here the responses to my questions, and
other tidbits that I received. For those who want to wade through the
mire of responses yourselves, I am making them available by anonymous
ftp (login "anonymous", password "guest) from dinorah.wustl.edu
(128.252.118.101) in the pub directory, files "portability.net" and
"conf.shar". If you want them, and can't ftp dinorah, let me know and
we can try to mail them.... The portability.net file is around 120 K,
just to warn you! 8^)
> 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
Whoops! The really embarassing thing is that I have no idea what I
wanted to say here. 8^)
>
> 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?
A lot of variation here. Guess ranged from 10% extra to T**N where T
is the indidividual host time and N is the number of hosts to port to.
Most people seemed to think that it would be between 25 and 100% extra
time, with the amount of time decreasing as we gain experience. A lot
depends on the type of code, not surprisingly.
>
> * Should some people develop and others port, or should we all
> learn to write portable code by porting what we write.
There were people who felt strongly on each side, but the general
sense of the responses was that each person must be responsible for
writing portable code. The most persuasive arguments (to me) and the
plan we are implementing is that each person will be responsible for
their own code, and must fix the non-portable features. One person
(yours, truly, aka Mr. Portability) is responsible for insuring that
all code written is, in fact, portable. Approximately 40% of my time
will be devoted to this now.
>
> * Any recommendations for a 386/486 box and/or operating system?
Not a lot of responses here. No clear winner on hardware, but
Interactive's 386/ix was a clear winner on OS. This isn't a personal
plug since I have never even seen a system running it, just a summary
of the responses.
>
> * Any major pitfalls to avoid? If we can learn from other's
> mistakes, that would be wonderful!
Major pitfalls include:
- sockets: Flaky, at best, on most SysV derived OS's.
- symbolic links: Frequently not available on SysV derived OS's
- filename length: Limited to 14 chars per segment on SysV derived OS's
- ioctls: Differ drastically from machine to machine
- signal control: Differ between BSD and SysV
- file locking: Non-portable and may not work over network (NFS)
- makefiles: Sys V and BSD have some differences; BSD is dumber
- # of sig. char in identifiers: can be as low as 8 in old compilers
- header files: move around, and change contents
- variable size/byte order: differs on different hardware
- job control: suspend/resume absent on SysV derived OS's
- differing library functions: need portability libraries
- differing function return codes: ditto
>
> * Any problems with using BSD sockets? X Windows? File system
> issues? Something else?
>
BSD sockets: Yes, lots, they don't exist or don't work on many Sys
V derived operating systems.
X Windows: Should be pretty portable. Have to watch that our code
is portable, not depending on fixed color scheme, depth, screen size,
etc.
File System issues: File locking is questionable at best.
Filename length can cause problems, NFS may or may not be available.
Something else: See above.
> * Any techniques that you have found helpful in doing this type of
> thing?
Several useful techniques. Notable among them is the use of
FEATURE-based #ifdefs, not operating system- or platform-based; use of
the C preprocessor on things other than .c and .h files; port early,
port often; portability libraries to provide a common interface to
frequently used calls. This isolates the dependencies to a small
section of code.
>
> 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.
I am sending this by e-mail to all who asked, and am posting this to
comp.sofware-eng, which was the winner in suggested summary groups.
>
> Thanks in advance!
and in arrears! 8^)
> -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.