🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.dec
Article #4600

Re: Porting to VMS-C

#4600
From: jt
Date: Wed, 25 Mar 1987 20:24
52 lines
2709 bytes
In article <199@ndmath.UUCP> milo@ndmath.UUCP (Greg Corson) writes:

>The application I am moving uses very few system calls...

That should make it easier...

>...the primary ones
>are used to switch from normal to RAW mode and back...

You lose.  Don't expect any help from the C runtime library.  Prepare to get
intimate with the I/O Users manual, in which the terminal driver programmer
interface is described.

> ..., vanilla fork&exec calls
>for loading up various utility programs...

You lose.  By "vanilla" you mean "unix-like".  On VMS you have vfork and
exec.  The vfork is really a setjmp, and the exec is a longjmp.  Between the
vfork and the exec, anything you do (like closes and dups) affect both the
parent and the child.  You MUST exec to ever get back to being the parent.
Prepare to get intimate with LIB$SPAWN and SYS$CREPRC if vfork and exec are
too wimpy for what you are trying to do.

> ... and a few misc system calls for finding
>tty names...

If you mean the name of a tty associated with an open file pointer, you win!
fgetname() will do the trick, you just have to clean up some VMS debris that
comes along with the name.

>... and file modification dates.

No sweat.  A semi-real stat() is standard equipment.  (It wasn't in VMS 3, but
you don't want to hear about that.)

>  All file IO is done with unbuffered
>read and write calls.

Good move.  Avoid standard I/O like the plague, and watch out for weird
behavior on reads when dealing with non-STREAM file types.  For example,
when reading text files (record format: variable, record attribute: cr), a
read will return a line of text at a time.  If file processing speed is any
consideration, prepare to get intimate with direct use of file QIOs.

Good luck.

-- 
=========================    `` ''    ====================================
Jerry Toporek               <`@-@'>             Network Research Corp.
ihnp4!nrcvax!jt              ( > )              1620 Federal Ave. Suite #2
ucbvax!calma!nrcvax!jt        \~/               LA, CA, 90025, USA
{sdcsvax,hplabs}!sdcrdcf!psivax!nrcvax!jt       (213) 479-6436
Technical Details
Message-ID: <827@nrcvax.UUCP>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!ut-sally!utah-cs!utah-gr!uplherc!nrc-ut!nrcvax!jt
References: <199@ndmath.UUCP>

Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: arc1-ca.pugleaf.net!utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!ut-sally!utah-cs!utah-gr!uplherc!nrc-ut!nrcvax!jt
From: jt@nrcvax.UUCP
Newsgroups: comp.sys.dec
Subject: Re: Porting to VMS-C
Message-ID: <827@nrcvax.UUCP>
Date: Wed, 25-Mar-87 15:24:51 EST
Article-I.D.: nrcvax.827
Posted: Wed Mar 25 15:24:51 1987
Date-Received: Fri, 27-Mar-87 06:26:43 EST
References: <199@ndmath.UUCP>
Reply-To: jt@minnie.UUCP (Jerry Toporek)
Organization: Network Research Corp.  Oxnard, CA
Lines: 52