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

[VAXman- at SendSpamHere.ORG]

In article <7lt9bbF3f65jjU1 at mid.dfncis.de>, js at cs.tu-berlin.de (Joerg Schilling) writes:
>In article <00A944D0.32BE9C1D 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.

OS following standards meaning it's a unix or unix derivative?

I follow standards when I write code.  I'll wager you'll have ONE HELL of a
time posting it to unix. ;)


>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.

fork/vfork is a unix function!!!  See my original statement.


BTW, I helped Eberhard when he ported your cdrecord to VMS. You made very big
assumptions about SCSI.


-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

  http://www.quirkfactory.com/popart/asskey/eqn2.png
  
  "Well my son, life is like a beanstalk, isn't it?"