carl@CITHEX.CALTECH.EDU (Carl J Lydick) (03/21/88)
> I got a message a few minutes ago (I wonder how many days it will be before > this message gets to people), saying that it is not possible in a practical > sense to "chain images". That is, "CALL" one image from another as if it > were just a subroutine. I didn't think it was possible either until a > message came in referring everyone to the LIB$FIND_IMAGE_SYMBOL routine (my > apologies to the person who posted it, I don't remember your name). I > wanted to see if it REALLY did what the manual seemed to say it did > (sometimes the routine descriptions which don't include examples are vague > or I'm simply too dumb to understand without an example). I looked in the > Master Index to see if there were any references to the routine other than > the description in the RTL manual. There were none and therefore no > examples (I assume) in the manuals. I'm one of the people who referred you to LIB$FIND_IMAGE_SYMBOL. Let me point out again that this works only with SHAREABLE images. This means that you can't chain most images that are linked to be run via a command from the DCL level. However, I've discovered that it is possible to run at least some shareable images via a DCL command; for example, TEST1, below, can be run that way, as well as by being called from TEST0). Here's a complete example of how to use LIB$FIND_IMAGE_SYMBOL from a VAX C program, including both the calling and the called program. Create a file, TEST0.C with the contents /******************************* TEST0.C BEGINS *******************************/ #include descrip main() { $DESCRIPTOR(filename,"TEST1"); $DESCRIPTOR(symbol_desc,"test1"); int (*fubar)() = 0, stat; if (((stat = LIB$FIND_IMAGE_SYMBOL(&filename,&symbol_desc,&fubar)) & 7) != 1) exit(stat); else (*fubar)(); puts("Goodbye, world!"); } /******************************** TEST0.C ENDS ********************************/ Compile it with the command: $ CC TEST0 Link it with the commands: $ LINK TEST0,SYS$INPUT:/OPT SYS$SHARE:VAXCRTL/SHARE ^Z Create a file, TEST1.C, containing: /******************************* TEST1.C BEGINS *******************************/ test1() { puts("Hello, world!"); return(1); } /******************************** TEST1.C ENDS ********************************/ Compile it: $ CC TEST1 Link it: $ LINK/SHARE TEST1,SYS$INPUT:/OPT SYS$SHARE:VAXCRTL/SHARE UNIVERSAL=test1 ^Z Define a logical name pointing to TEST1 $ DEFINE TEST1 'F$ENVIRONMENT("DEFAULT")'TEST1 Then run TEST0: $ RUN TEST0 Note that TEST1 can also be run from the DCL level: $ RUN TEST1 Hope this is useful to you.
garry@batcomputer.tn.cornell.edu (Garry Wiegand) (03/28/88)
In a recent article carl@CITHEX.CALTECH.EDU (Carl J Lydick) wrote: >I'm one of the people who referred you to LIB$FIND_IMAGE_SYMBOL. Let me point >out again that this works only with SHAREABLE images. This means that you >can't chain most images that are linked to be run via a command from the DCL >level... Now, if you want to be a real wiz, what you do is: A) get your DCL command line from wherever and nibble off the command verb. Either use a hard lookup table (ie, "DELE" -> SYS$SYSTEM:DELETE) or a program like Verb as a subroutine to find the right image to activate. B) Activate that image with SYS$IMGACT - it doesn't have to be a shareable image. C) call Find_Image_Symbol on DCLTABLES.EXE to get the address of the real DCL tables (the name I forget, use ANAL/IMAGE to see it) (the tables are up in P1 space too, I think, if you prefer) D) Tell CLI to parse up the command line please E) Call the entry point of DELETE, DIRECTORY, or whoever the image turned out to be *as a subroutine*. It don't know/can't tell that it isn't running as a normal DCL call, calls CLI like usual, and everything works out. I leave trapping out possible SYS$EXIT calls from the called program as an exercise for the reader. I used to have the code for this and a bunch of other nonsense 3-4 years, but I just looked around in all the dusty places and don't see it anymore. ((Before we got involved in graphics, we were playing some ideas for some new VMS utilities. I got involved in the above in the course of adding an some new switches/abilities to existing VMS commands - I could have just duplicated the previous VMS functionality and gone on, but that was tedious and I also didn't want to have to *keep* duplicating DEC's functionality. So we just used Dec's programs as subroutines of our own.)) Oh, the functionality involved was an "UNDELETE" command, with related switches DIR/DELETED, DELETE/REALLY, etc etc etc. All blended in nicely. Cute. (Normal-delete became a surreptious Rename to an invisible parallel directory tree.) Never did get around to trying to sell the various things - people still are just barely interested in non-Dec *hardware* - VMS add-on software was/is an even tougher row to hoe. garry wiegand (garry@oak.cadif.cornell.edu - ARPA) (garry@crnlthry - BITNET)