LEICHTER-JERRY@YALE.ARPA.UUCP (06/12/86)
Back in early January, someone on INFO-VAX asked for methods to build version- independent images - images that could be moved to EARLIER versions of VMS without problems. (You can generally move to LATER versions as long as you "play by the rules".) At the time, I wrote a note recommending the use of /NOSYSSHR as a means for doing this. A friend at DEC sent me some comments on this, suggesting that I might want to forward them; but we ran into some severe network problems at the time, and my messages never got through. Well, today I was cleaning out my mailbox, and found said message. It's just as relevent now as 6 months ago, so I decided to pass it on. -- Jerry Jerry: I saw your note in INFO-VAX recommending the use of /NOSYSSHR to achieve version-independence. While this usually works, I have been trying to stomp out use of /NOSYSSHR for the following reasons: 1. Some changes in the RTL are meant to correspond with changes in VMS. DEC makes no promises that even an object from a 4.2 RTL (say) will work properly under 4.1. 2. Many RTL routines are not shipped in object form anymore. MicroVMS has none of the object-form routines that duplicate those in shareable images. Even full VMS is missing some - for example, the object forms of the callable SORT routines have never been in the distributions. 3. Linking /NOSYSSHR denies the user all of the advantages of using shared images, such as memory sharing, automatic bug fixes, smaller image sizes, etc. The proper way to be version independent is to link your images against the lowest version of VMS that you want to support. Generally, all this involves is keeping a copy of the shareable images, STARLET.OLB and IMAGELIB.OLB from the earliest version (say V4.0). If you put those in a directory and define SYS$LIBRARY to point to that directory, the linker will automatically link against the older files. Keeping a copy of LINK.EXE and using that (by defining a LINK logical) is also a good idea, as that protects you against changes in the image formats. In the particular case of linking against the C RTL, linking against the objects for C only is probably OK. There was once a separate license for the C RTL, but no longer. In the general case, the RTL group is taking steps to reduce the need for changing the global section match idents of RTL images when new routines are added. This involves adding dummy entries into the transfer vector which, if called, signal an error. New routines replace the dummy entries as needed. If you then take an image back a version, it will run fine as long as it doesn't call one of the new routines not present in the old version; if it does, the dummy routine signals an error. -------