[Info-vax] Looking into C-include files on VMS

[John Wallace]

On Nov 10, 1:49 pm, j... at cs.tu-berlin.de (Joerg Schilling) wrote:
> In article <00A944D0.32BE9... at SendSpamHere.ORG>,
>  <VAXman-  @SendSpamHere.ORG> wrote:
>
> >Exactly!  That's why the effort is called "porting" and not "compiling and
> >linking".  If there is something that doesn't exist to support the feature,
> >the person "porting" the code needs to redesign/recode that portion of code.
> >The end results should be the same.  Get the fork out of there and rewrite
> >the code to work with some other scheme supported in the OS.
>
> How much code did you port already?
>
> Decently (portably) written software just needs a recompile if this is done
> on an OS that follows standards.
>
> Problems usually arise if an OS supports interfaces that use well known names
> but does not implement the well known funktionality with these interfaces or
> if interfaces are implemented in an incomplete way.
> Let me give you examples:
>
> -       An inttypes.h that does not define maxint_t is a portability problem
>
> -       A vfork() that does not behave like vfork is a portability problem.
>
> --
> EMail:jo... at schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
>       j... at cs.tu-berlin.de             (uni)  
>       joerg.schill... at fokus.fraunhofer.de (work) Blog:http://schily.blogspot.com/
> URL:  http://cdrecord.berlios.de/private/ftp://ftp.berlios.de/pub/schily

"Decently (portably) written software just needs a recompile if this
is done on an OS that follows standards."

UNIX is a portability problem. If UNIXes was consistent across
versions and implementations, configure scripts would be unnecessary.
But UNIXes aren't consistent, not even now, how ever many years since
the Single UNIX Specification was introduced (POSIX.1 in 1996?) or
since the Linux Standards Base was introduced (2001?). APIs are
inconsistent across implementations even in userland never mind in the
kernel, shells and shell commands vary, file system layouts vary, etc.
Portable?

When I first came across UNIX (1985), the AT&T camp couldn't even
agree with the BSD camp on how many parameters there should be in a
call to open() a file. They've fixed that one, but there are plenty
others still to sort out.

Properly written user mode VMS V1 source still compiles and runs on
VMS V8, thirty years later. Not just "hello world" but real
applications. No porting necessary, so long as you don't mind sticking
with VMS as the OS.  Same goes for user mode executables - they just
work. VMS has made very very few changes to documented things such as
file system layouts. VMS drivers and kernel mode stuff may need a few
changes depending on the relative age of the before and after stages,
but on the whole these interfaces have been relatively stable and well
documented.

Try that kind of thing on any UNIX with any application significantly
more complicated than "hello world", especially if the start and end
stages are more than a few versions apart, and it becomes a porting
exercise. Don't even think about trying to port a driver; at least
with Linux, kernel mode API stability between versions is explicitly a
non-goal. On the other hand you may be able to use the same driver
source on everything from ARM to IA64, so long as it's the same kernel
version and same endianness and...

Summary: UNIX people in general should be extremely careful before
talking about standards conformance and how good UNIX is at it,
because in general it's still not very good at it at all. What it is
good at is providing low cost lowest common denominator functionality
nearly compatibly across a wide variety of (mostly) low cost hardware,
and quite a lot of people think that has value (me included). But
that's very little to do with real standards.