From:	CSBVAX::CSBVAX::MRGATE::"SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX"  9-MAR-1989 05:50
To:	MRGATE::"ARISIA::EVERHART"
Subj:	Re: VMS C Library - Beware of using the old .OLB


Received: From KL.SRI.COM by CRVAX.SRI.COM with TCP; Wed,  8 MAR 89 15:26:18 PDT
Received: from ucbvax.Berkeley.EDU by KL.SRI.COM with TCP; Wed, 8 Mar 89 15:20:00 PST
Received: by ucbvax.Berkeley.EDU (5.61/1.36)
	id AA00886; Wed, 8 Mar 89 13:25:39 -0800
Received: from USENET by ucbvax.Berkeley.EDU with netnews
	for info-vax@kl.sri.com (info-vax@kl.sri.com)
	(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 7 Mar 89 21:04:49 GMT
From: munnari!otc!metro!basser!usage!csdvx0!decus!taylort@uunet.uu.net  (Trevor Taylor)
Organization: DECUS, Australian Chapter
Subject: Re: VMS C Library - Beware of using the old .OLB
Message-Id: <689@decus.com.au>
References: <1726@mas1.UUCP>, <3487@stiatl.UUCP>
Sender: info-vax-request@kl.sri.com
To: info-vax@kl.sri.com

In article <3487@stiatl.UUCP>, todd@stiatl.UUCP (Todd Merriman) writes:
> In article <1726@mas1.UUCP> condor@mas1.UUCP (Rick Kawala) writes:
>>I want to write a program in C and then give the executable image
>>to a company which is licensed for VMS but not for the C compiler.
> 
> As of VMS Ver. 4.4 (I think), VAXCRTL (VAX-C Run-Time Library) was 
> bundled with VMS, partially because DEC was distributing software
> developed under C (MMS).  

Yes, VAXCRTL.EXE and VAXCRTLG.EXE have been distributed since
VMS 4.4 (about 18 months now). The `G' version uses G-float.

Because these are sharable images, you link with them slightly
differently (although the other language groups seem to have
resolved this problem, but the `C' people haven't):

	$ LINK MYPROG,VAXC/OPTIONS

where VAXC.OPT contains one line:

SYS$LIBRARY:VAXCRTL/SHARE


The really interesting point it that many customers who had VAX C
before VMS V4.4 still have the old VAXCRTL.OLB object library and 
are still linking against it even today!!! This is because they have
defined a logical name LNK$LIBRARY to point to it and it is searched
automatically by the linker. In other words, they have not had any
of the benefits of bug fixes to the RTL for almost two years ...
(Or maybe they have judging by the C bugs being reported in this
newsgroup ...)

Another interesting point is that ORACLE distributed the DEC
VAXCRTL.EXE along with their database product for a long time
(maybe they still do) under the name ORACRTL.EXE. However, 
if you did an ANALYZE/IMAGE, all was revealed! This was an obvious
rip-off from the time when DEC was charging for run-time licences.
It amazes me that DEC didn't really get stuck into ORACLE over this.

Once again though, the interesting part is that this image is miles
out of date. In particular, a C function called strtok() does not
exist in this old version of the library. This causes all sorts of
interesting problems if you try to use the real VAXCRTL.EXE because
the ORACLE link procedure actually fiddles with the virtual address
space and bases certain PSECTs at specific addresses. The new (DEC) 
version is larger and blows them away. The local ORACLE people tried 
to tell me that this was DEC's fault for increasing the size of the 
library code!!! Admittedly this was a while ago, so maybe it is
fixed now, but it only goes to show that run-time licences are a 
bad idea from the start. So what's this I hear about run-time Rdb
being included in VMS V5.1 ???

	Trevor