perl@rdin.UUCP (Robert Perlberg) (08/06/85)
Is the VAX VMS C-compiler compatible with UNIX? That is, can I take
C files that compiled under UNIX and compile them under VMS with no
changes other than the shell commands inside of system() calls? A guy
in my office says that to hope for this is naive at best, but I thought
that this ability was supposed to be a feature of C.
Another thing I'm looking for under VMS is the ability to load both
C and FORTRAN object files into one executable. Does anyone know if
this works?
Robert Perlberg for Susan Hovde
Resource Dynamics Inc.
New York
{philabs|delftcc}!rdin!perl
{philabs|delftcc}!rdin!sjheric@grkermi.UUCP (Eric N. Starkman) (08/08/85)
In article <488@rdin.UUCP> perl@rdin.UUCP (Robert Perlberg) writes: >Is the VAX VMS C-compiler compatible with UNIX? That is, can I take >C files that compiled under UNIX and compile them under VMS with no >changes other than the shell commands inside of system() calls? A guy >in my office says that to hope for this is naive at best, but I thought >that this ability was supposed to be a feature of C. VMS C does a pretty good job of looking like Unix C, but there are a number of things under the UNIX operating system that it's sort of difficult to emulate under VMS. Consider stat(2), for instance; the nature of the VMS file system just doesn't lend itself to duplicating that call. >Another thing I'm looking for under VMS is the ability to load both >C and FORTRAN object files into one executable. Does anyone know if >this works? Object code is object code. As far as sharing data, VMS C externs correspond to FORTRAN common blocks. Each extern resides in it's own program section. VMS C also has 'global' types which correspond to a global symbol in assembly language. (All from the VAX/VMS C manual, V1.0, chapters 10 and 11) -Eric Starkman arpa: starkman@athena.MIT.EDU uucp: ...decvax!genrad!panda!ens
rdp@teddy.UUCP (08/08/85)
In article <488@rdin.UUCP> perl@rdin.UUCP (Robert Perlberg) writes: >Is the VAX VMS C-compiler compatible with UNIX? That is, can I take >C files that compiled under UNIX and compile them under VMS with no >changes other than the shell commands inside of system() calls? A guy >in my office says that to hope for this is naive at best, but I thought >that this ability was supposed to be a feature of C. > >Another thing I'm looking for under VMS is the ability to load both >C and FORTRAN object files into one executable. Does anyone know if >this works? > When I was working for Applicon, I convinced people to get the Decus C compiler in house. Previous to that, the standard language was a severely bastardized PL/I (bletch!). My experiences follow: With the exception of some RMS-specific stuff (needed to gbet around the insistance of the stdio routines to do things exactly like unix) I was able to code my applications using direction from UNIX documentation. Seldom, if ever, did I refer to the VMS C documentation for specific features or bugs. I was able to port one RATFOR compiler over to VMS (it did not use YACC or LEX) with no source changes at all. What changes I made were to support VMS DCL argument style. It was pretty simple. I also had the occasion to interface quite a bit to FORTRAN and PL/I routines from C, and vice versa. This was very, very simple. The only thing you have to remember is that FORTRAN expects call by reference, whereas C passes by value. This was solved by calling fortran routines from C and passing pointers to all arguments. If you need to call a C library routine from FORTRAN, and need to pass by value, the VMS "%VAL" descriptor works fine. All in all, I went through the same situation as yours with very little trouble. I did not use very UNIX dependent routines, and that helped a lot. I might even venture to say, knowing I will be severely flamed for it, that developing UNIX apllications is much easier under VMS than UNIX. But I know better than to tilt at sacred windmills.
pritch@osu-eddie.UUCP (Norman Pritchett) (08/09/85)
> Is the VAX VMS C-compiler compatible with UNIX? That is, can I take > C files that compiled under UNIX and compile them under VMS with no > changes other than the shell commands inside of system() calls? A guy > in my office says that to hope for this is naive at best, but I thought > that this ability was supposed to be a feature of C. In my opinion, DEC made a half-decent effort to make Vax-11 C compaitible with Unix C. Generally, all but the things which just cannot be done in VMS or wouldn't make sense in VMS were preserved. Areas you will have problems with are things that manipulate terminal characteristics, file i/o (sometimes), things that depend heavily on shell features (wildcard expansion, i/o redirection). > Another thing I'm looking for under VMS is the ability to load both > C and FORTRAN object files into one executable. Does anyone know if > this works? > That's part of VMS. The VMS concept is that all routines should be callable from any language. The questions you've asked can be best answered by reading "Programming in Vax-11C" which is put out by DEC. -- ----------------------------------- Norm Pritchett UUCP: cbosgd!osu-eddie!pritch CSNET: pritch@ohio-state Bellnet: (614) 422-2810
stpeters@steinmetz.UUCP (R L StPeters) (08/09/85)
> ... can I take > C files that compiled under UNIX and compile them under VMS with no > changes other than the shell commands inside of system() calls? No. Not unless they're pretty trivial. > Another thing I'm looking for under VMS is the ability to load both > C and FORTRAN object files into one executable. Does anyone know if > this works? Yes, it does, if you're carefull. -- R. L. St.Peters (Dick) The "R" is for "Reptile". uucp: decvax!mcnc!ncsu!uvacs!edison!steinmetz!stpeters (uucp is forever) arpa: stpeters@ge-crd (federal express) "Any opinions expressed by my employer are probably not mine."
daveb@rtech.UUCP (Dave Brower) (08/09/85)
> Is the VAX VMS C-compiler compatible with UNIX? That is, can I take > C files that compiled under UNIX and compile them under VMS with no > changes other than the shell commands inside of system() calls? No. You will likely need to run some sed scripts over things to take into account different # include statement syntax. DEC-C also does not know about the void type. These are mostly annoyances, not show stoppers. > Another thing I'm looking for under VMS is the ability to load both > C and FORTRAN object files into one executable. Does anyone know if > this works? Yes. This is a BIG selling point. Almost all of DEC's language products use a compatible calling convention and object format. -- {amdahl|dual|sun|zehntel}\ |"If his brains ran down, how could {ucbvax|decvax}!mtxinu---->!rtech!daveb |he talk?" ihnp4!{phoenix|amdahl}___/ |"Happens to people all the time...."
eric@grkermi.UUCP (Eric N. Starkman) (08/09/85)
In article <541@grkermi.UUCP> I write: > Consider stat(2), for instance; >the nature of the VMS file system just doesn't lend itself to >duplicating that call. I just found a copy of the VMS C manual, version 2.0. They have implemented the stat call. The inode is translated to the file id, the mode is kluged, and they even store some RMS FAB info there. -Eric Starkman arpa: starkman@athena.MIT.EDU uucp: ...decvax!genrad!panda!ens
cdshaw@watmum.UUCP (Chris Shaw) (08/12/85)
In article <488@rdin.UUCP> perl@rdin.UUCP (Robert Perlberg) writes: >Is the VAX VMS C-compiler compatible with UNIX? That is, can I take >C files that compiled under UNIX and compile them under VMS with no >changes other than the shell commands inside of system() calls? A guy >in my office says that to hope for this is naive at best, but I thought >that this ability was supposed to be a feature of C. > I tried porting Kermit from UNIX to VMS once, and it was a real bother.. all to do with system dependencies (tty names, etc) AND the way I/O was handled. VMS is very record-ish, while stream i/o is the unix thing. Unfortunately, port didn't work because we didn't really spend the effort required to do the QIO's required to fake stream i/o on VMS. Other than that, porting is reasonably ok, but it was the terminal-driver part of the code that really made us chew steel wool. Chris Shaw watmath!watmum!cdshaw or cdshaw@watmath University of Waterloo Revolution is the opiate of the intellectuals.
oz@yetti.UUCP (Ozan Yigit) (08/14/85)
In article <589@rtech.UUCP> daveb@rtech.UUCP (Dave Brower) writes: >... DEC-C also does not >know about the void type. These are mostly annoyances, not show >stoppers. > Wrong. New DEC-C compiler knows about void types. It even has curses. (Although they have done other changes that may cause headaches :-) Btw: The well known case statement inefficiency is now fixed. It no longer generates huge jump tables for case statements unless that is the most efficient code generation strategy. -- Usenet: [decvax|allegra|linus|ihnp4]!utzoo!yetti!oz Bitnet: oz@[yuleo|yuyetti] You see things; and you say "WHY?" But I dream things that never were; and say "WHY NOT?" G. Bernard Shaw (Back to Methuselah)
pritch@osu-eddie.UUCP (Norman Pritchett) (08/21/85)
cdshaw writes: > VMS is very record-ish, while stream i/o is the unix thing. Unfortunately, > port didn't work because we didn't really spend the effort required to do > the QIO's required to fake stream i/o on VMS. Huh? On input Vax-11 C converts records with any attribute (implied carriage control, print carriage control, FORTRAN carriage control, null, and VFC) to stream format (read your "Programming in VAX-11 C" book AA-L370A-TE) so everything always looks like stream files on input. On output, Vax-11 C creates stream files unless you go through the immense amount of effort to specify otherwise. -- ----------------------------------- Norm Pritchett UUCP: cbosgd!osu-eddie!pritch P.O. Box 3393 CSNET: pritch@ohio-state Columbus OH 43210 BITNET: TS1703 at OHSTVMA Bellnet: (614) 422-0885