Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!cornell!batcomputer!tedcrane
From: tedcrane@batcomputer.tn.cornell.edu (Ted Crane)
Newsgroups: comp.os.vms
Subject: Re: Need faster VMS spawn
Message-ID: <890@batcomputer.tn.cornell.edu>
Date: Tue, 5-May-87 10:04:13 EDT
Article-I.D.: batcompu.890
Posted: Tue May  5 10:04:13 1987
Date-Received: Thu, 7-May-87 06:31:23 EDT
References: <8704230311.AA00968@uvabick.UUCP> <633@cognos.UUCP>
Reply-To: tedcrane@tcgould.tn.cornell.edu.UUCP (Ted Crane)
Distribution: world
Organization: Program of Computer Graphics, Cornell University
Lines: 34

In article <633@cognos.UUCP> jimp@cognos.UUCP (Jim Patterson) writes:
>I'm replying to your posting just to correct some apparent misunderstandings
>about a few of the VMS services.
>
>>You will have to look at the System Services manual to find out what it's
>>called, but I know that there is also a "exec"-like routine that overlays all
>>or part of your address space with a new program image.  
>
>You won't find this in the system services manual.  The routine you're
>referring to is the image activator, and it's used by DCL to merge a user
>program or image into the process address space as part of a RUN command.

Jim's right, there is an undocumented system service which interfaces to the
image activator.  There is also a Run Time Library routine called

	LIB$FIND_IMAGE_SYMBOL

which presents a limited interface to the image activator.  It will locate
an image on disk, map it into your address space, and return to the caller
the value of a global symbol from that image.  Usually, that value is the
address of a routine entry mask, and the caller can then call the routine.
If you call LIB$FIND_IMAGE_SYMBOL again (with the same image name), it is
smart enough not to map the image again--it just returns the global symbol value
from the existing image.

This technique can be used to some advantage, like not including whole portions
of your program unless they are really going to be used (example: ANAL/ERRLOG
is divided into many such images, and are bound up at run time).  Unlike
sharable images, if you aren't going to call routines in the image, the image
need not even exist on disk!

One catch: the errors returned by LIB$FIND_IMAGE_SYMBOL are sometimes less
than helpful.  For example, something like "invalid key in library" (a
librarian message) when you look for a symbol that isn't in the image!