Xref: utzoo comp.os.vms:15934 comp.windows.x:11567
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!tedcrane
From: tedcrane@batcomputer.tn.cornell.edu (Ted Crane)
Newsgroups: comp.os.vms,comp.windows.x
Subject: Re: DECWindows "Dummy" Shareable Images
Keywords: decwindows, shareable, sharable, VWS
Message-ID: <8409@batcomputer.tn.cornell.edu>
Date: 14 Jul 89 22:46:14 GMT
References: <1140@io.UUCP>
Reply-To: tedcrane@tcgould.tn.cornell.edu (Ted Crane)
Organization: Tompkins County Computing, Ithaca, NY
Lines: 18

In article <1140@io.UUCP> bcking@io.UUCP (Christine King x4426) writes:
>Somebody besides us must be having this problem, so here's our
>solution.  You want to build an executable image that works in
>either a VWS (UIS) or a DECWindows environment.  So you write a
>bunch of code that detects what's present and takes the appropriate
>path at runtime.  But the problem is that the image you have built

Another way to go about this is to use the VMS routine LIB$FIND_IMAGE_SYMBOL.
After you have determined that you are running w/ UIS or DECwindows, you
use this routine to look up the transfer address of every routine you
need to use.  Since you are passing string arguments to FIND_IMAGE_SYMBOL,
there are no "real" global references in your program.  Thus, neither
the UIS or DECwindows sharable images are linked to your program (the 
first call to FIND_IMAGE_SYMBOL for a given image will load the appropriate
image and merge it into your address space).

Yes, this is messy.  Don't complain to me, though, I just thought I'd
mention it...