rouil@ada-uts.UUCP (08/09/85)
Sorry for posting this to the net but mail gagged .... Dec puts out a manual called Programming in VAX-11 C the number is AA- L370A-TE. In appendix A there is a listing of supported/nonsupported functions. If you are going to use a lot of system calls think twice before porting. You have to use VMS System service routines and you have to learn the calling syntax and types. The routines give you more power (in my opinion) but they are a pain to call at times. Get someone who is experienced with Sys. Serv. routines to give you a hand with recoding system() calls to the System Service routines. John Rouillard Phone:(617) 661-1840 Intermetrics Inc. 733 Concord Ave Net: {harpo, bellcore, ihnp4}! Cambridge, Ma. 02138 inmet!ada-uts!rouil "Caution the Surgeon General has determined that these thoughts can be dangerous to your health. Read at your own risk."
tp@ndm20 (08/10/85)
>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? It is supposed to but some while ago, there was a discussion on INFO-VAX saying that C in some way violated the VMS procedure calling standard. Thus there is one or more obscure case that fails. This is ironic in that the calling standard is highly touted by DEC. This discussion predated VMS4, so they may have fixed it. There is also a general rule that happens to apply in this case, that I/O can only be done from routines in the same language as the main. This is because that is where most compilers on most machines put the calls to the I/O system initializers, and few languages share I/O systems. On some machines, you can't even do it if there are routines of another language between the main and the routine in question. At least part of the above statement is not true of C and f77 on Unix, as they share a common I/O library. (I am not a Unix guru, please no flames about that) For more info, I suggest you post you question to INFO-VAX. Terry Poot Nathan D. Maier Consulting Engineers (214)739-4741 Usenet: ...!{allegra|ihnp4}!convex!smu!ndm20!tp CSNET: ndm20!tp@smu ARPA: ndm20!tp%smu@csnet-relay.ARPA
stern@bnl.UUCP (eric) (08/17/85)
> >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? > > It is supposed to but some while ago, there was a discussion on > INFO-VAX saying that C in some way violated the VMS procedure calling > standard. Thus there is one or more obscure case that fails. This > is ironic in that the calling standard is highly touted by DEC. This > discussion predated VMS4, so they may have fixed it. I don't know if I would make too much of this. The procedure calling calling standard is only that and nothing more. The fact that I can violate the standard in C, is just a function of the fact that I can do most anything in C. I can violate the standard by doing certain things in MACRO also, so this is just another example of "I can do anything in C that I can do in MACRO". There are rather simple rules to follow if you are programming in C and are interfacing to other languages to make a program comply with the procedure calling standard. Note that there is no problem if a program is entirely written in C, so that this problem will not effect the porting of existing C programs. > There is also a general rule that happens to apply in this case, that > I/O can only be done from routines in the same language as the main. > This is because that is where most compilers on most machines put the > calls to the I/O system initializers, and few languages share I/O > systems. On some machines, you can't even do it if there are routines > of another language between the main and the routine in question. This may have been the case in an old version of VMS, but it certainly isn't correct now. I regularly mix FORTRAN and PASCAL I/O, and I just verified that I can do C standard I/O mixed with PASCAL I/O. In VMS run-time systems, initialized data is linked in the run-time libraries as initialized copy-on-reference data, and so no initialization needs to be done at run time. The biggest problem one is likely to run into when mixing I/O to the terminal is that FORTRAN, PASCAL, and C all have different ideas about carriage control, and each maintains a separate picture of what carriage control characters are necessary. > Terry Poot > Nathan D. Maier Consulting Engineers > (214)739-4741 > Usenet: ...!{allegra|ihnp4}!convex!smu!ndm20!tp > CSNET: ndm20!tp@smu > ARPA: ndm20!tp%smu@csnet-relay.ARPA In general, C programs that do I/O with standard I/O library interfaces (getc, printf, etc...), use math library functions, and that don't use things like stat and ioctl can be expected to work unmodified on VMS systems. Programs that use (read, write, open, creat) will work in many cases, although they will have to be looked at carefully. In particular, the file formats may cause a problem. Programs that rely on forking/vforking and pipes will probably need major changes to run. DEC supplies an implementation of vfork and pipes, but it is so limited that I suspect it may not be useful. Still, if your program happens to fall within the limitations, it may run, although with a severe performance problem. There are many miscellaneous routines supplied for compatabilility with UNIX, and if a program uses them, there is a large chance it will work for both UNIX and VMS. This compatability has expanded a lot in the last release of the C compiler and I have not had a chance to fully explore the new stuff. It looks like there is even a curses. Eric G. Stern Dept. of Physics SUNY StonyBrook stern@bnl.arpa stern@bnl.bitnet stern@bnldag.bitnet ...!philabs!sbcs!bnl!stern