Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!tektronix!hplabs!ucbvax!YALE.ARPA!LEICHTER-JERRY
From: LEICHTER-JERRY@YALE.ARPA
Newsgroups: mod.computers.vax
Subject: Re: Re: Missing VMS 4.4 VAXCRT[lg].OLB files
Message-ID: <8609211251.AA16515@ucbvax.Berkeley.EDU>
Date: Sun, 21-Sep-86 08:51:59 EDT
Article-I.D.: ucbvax.8609211251.AA16515
Posted: Sun Sep 21 08:51:59 1986
Date-Received: Sun, 21-Sep-86 20:09:46 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: <LEICHTER-JERRY@YALE.ARPA>
Organization: The ARPA Internet
Lines: 39
Approved: info-vax@sri-kl.arpa

[The discussion involved the tradeoffs between using the object and shareable
image versions of the C library.]

    1) ... You also get an extra image to be activated every time you run your
    application.  In most cases that's not worth worrying about.  Then there
    are those rare times when it *does* matter.
Hmm...I guess this COULD be an issue, but if VAXCRTL.EXE is installed, I think
it's likely to be a tradeoff between one extra image activation and extra I/O
for a larger image - which could easily go either way.

    2) In addition to the bug fixing that comes along with VMS updates, it's
    not unheard of to see new bugs introduced.  Yes, even from DEC, and yes in
    the RTLs.  A product of my employer's was hit with such a problem with VMS
    4.4.  Fortunately the problem was only annoying and had no consequential
    impact for our customers.  Even more fortunate is the fact that these
    kinds of problems are very rare.
There's a work-around:  Keep a copy of the old RTL around, as VAXCRTL_OLD, for
example.  Then ASSIGN wherever:VAXCRTL_OLD VAXCRTL before running the program.
This is the best general solution for all sorts of cases where stuff isn't
QUITE upward compatible.

    Conclusion: know your options and the implications, then use the shared
    images unless you have a *really* good reason to do otherwise.
Absolutely.

    True, but sometimes you can fake it by creating a Shared Image Library
    which contains references to the shared images you want to link against.
    Your program still gets linked to the shared images, but you can usually
    avoid a Linker Options file.  Unfortunately, there have been documented
    problems in the past with shared image libraries which refer to
    VAXCRTL.EXE.  I don't know if the problems still exist in VMS 4.4.
Yes, there was some sort of annoying problem with the I/O library; stuff ended
up being based because of a non-PIC reference.  It may very well be fixed by
now, though I can't say I've tried it.  Certainly would be nice if it were.

    "A dog is a dog until he faces you.  Then he is Mr. Dog." - haitian farmer
Neat saying.
							-- Jerry
-------