Path: utzoo!attcan!uunet!snorkelwacker!usc!cs.utexas.edu!yale!cmcl2!lanl!u096000
From: u096000@lanl.gov (Roger A. Cole)
Newsgroups: comp.realtime
Subject: Re: VxWorks and SysV ?
Summary: VxWOrks is only superficially compatible with SunOS 4.x
Message-ID: <57182@lanl.gov>
Date: 16 Jul 90 19:49:13 GMT
References: <1990Jul11.140626.21657@bcars267> <9746@discus.technion.ac.il>
Distribution: comp.realtime
Organization: Los Alamos Natl Lab, Los Alamos, N.M.
Lines: 27


I have some input on the issue of VxWorks compatibility.  To put my
comments in perspective, you should know that I have only 1 year
experience with UNIX (SunOS) and VxWorks.

What I have found is that VxWorks and SunOS are, at best, compatible
only superficially.  Incompatibilities start with names of header files
and escalate.  VxWorks pipes aren't the same as SunOS pipes; VxWorks
select() works only on sockets; VxWorks task and semaphore routines don't
have direct counterparts under SunOS; the VxWorks "C library" has differences
from the SunOS C library; etc.

My goal with my work has been to compose a program which will compile for
either SunOS or VxWorks, and which will operate "the same" under both.  I
have partially achieved this goal with some "compatibility code" which
mimics (under SunOS, using lightweight processes and the non-blocking
i/o library) the VxWorks features I need.

The bottom line for me is: 1) I can have source level compatibility with
some restrictions and with some decrease in my productivity; 2) there is
losts of room for improvement in VxWorks; and 3) many VxWorks claims to
compatibility are dangerously misleading.

I get my work done with VxWorks, and I don't have any real regrets about
using VxWorks, but it definitely isn't a bed of roses.

Roger Cole, Los Alamos National Laboratory,  internet: cole@luke.LANL.GOV