home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky vmsnet.internals:1405 comp.os.vms:16181
- Newsgroups: vmsnet.internals,comp.os.vms
- Path: sparky!uunet!stanford.edu!agate!spool.mu.edu!uwm.edu!linac!att!cbnewsk!cbnewsj!att-out!pacbell.com!decwrl!pa.dec.com!nntpd2.cxo.dec.com!adserv.enet.dec.com!winalski
- From: winalski@adserv.enet.dec.com (Paul S. Winalski)
- Subject: Re: VMS shareable images, what's wrong with them?
- Message-ID: <1992Oct7.174849.22585@nntpd2.cxo.dec.com>
- Lines: 18
- Sender: usenet@nntpd2.cxo.dec.com (USENET News System)
- Reply-To: winalski@adserv.enet.dec.com (Paul S. Winalski)
- Organization: Digital Equipment Corporation, Nashua NH
- References: <Bvo7FC.M01@ithaca.com> <1aubqgINNbhn@gap.caltech.edu>
- Date: Wed, 7 Oct 1992 17:48:49 GMT
-
-
- In article <1aubqgINNbhn@gap.caltech.edu>,
- carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes a very snide and insulting
- flame challenging those who criticize the VMS method of shareable image version
- checking to come up a method of solving the backwards-incompatibility checking
- problem without using shareable image version numbers.
-
- Here is one approach that solves the problem. First, you do away with
- transfer vectors and instead bind the references to routines in a shareable
- image at run-time (this is in fact the way that Alpha AXP OpenVMS does it).
- Second, you do away with the shareable image version ID and replace it with a
- separate version ID for each entry point. That way, a program that doesn't
- use any of the new stuff in a shareable image can still run against an older
- version of the shareable image. The only cases where you get the backwards
- compatiblity problem is where you are actually calling routines that have
- backwards compatibility problems.
-
- --PSW
-