NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/sys/hp/13237

Text File | 1992-11-22 | 3.4 KB | 68 lines

Newsgroups: comp.sys.hp
Path: sparky!uunet!cs.utexas.edu!usc!rpi!think.com!sdd.hp.com!hpscit.sc.hp.com!scd.hp.com!hpscdm!cupnews0.cup.hp.com!hamilton
From: [e-mail] (Eric Hamilton)
Subject: Re: HP-UX 9.0 compatibility questions.
Sender: [e-mail]
Message-ID: <[e-mail]>
Date: Mon, 23 Nov 1992 06:00:17 GMT
References: <[e-mail]>
Organization: Hewlett-Packard
X-Newsreader: TIN [version 1.1.4 PL6]
Lines: 55

You should definitely check out the 9.0 release notes for details such as this
(see /etc/newconfig/90RelNotes/hpuxsystem).  I don't have them handy and some
of this may not be in them so I'll answer in general only.

Our general policy on binary compatibility is that we work very hard to
ensure that executables built on one rev of HP-UX will work on subsequent
releases on the same hardware.  This applies to executables using both
shared and archive libraries.  It is a major engineering design criterion
for changes and additions to HP-UX.

You also mentioned linking objects built on an earlier version with objects
built later.  To the best of my knowledge this is unsupported, although we
don't go and break this willy-nilly.  It is potentially valuable for some
customers and third-party library suppliers, but it can also be costly to
avoid breaking this, so I don't believe we support it.  There have been cases
in the past where we have not allowed this between releases due to changes in
the compilers or libraries, so it is not a good idea to count on it, though it
may work for you sometimes.

[The following is more from the "cold dead fish" school of marketing and might
make HP legal a little happier, except of course that this isn't an official
statment of HP and they'd probably prefer that I not say any of this at
all :) ]

We do things like keep multiple versions of system calls that have changed in
the kernel or use shared library versioning in order to support binary
compatibilty for executables.  Sometimes we do drop features or introduce
other incompatibilities between releases (to the great chagrin of customers
for whom those features were crucial).  If your application peeks at kernel
data structures, uses undocumented interfaces, uses features that have been
replaced with other standards, or replaces bundled HP software (e.g.  login)
then you are more likely to encounter incompatibilities.  The closer your
program is to being strictly standards conformant, the better the binary
compatibility story is.

You may also find that third party software or even layered software products
from HP don't work or aren't supported on new HP-UX revisions.  In order to
reduce their support matrixes and adequately test their systems, some vendors
require you to upgrade to later versions of their products if you are running
on a later version of HP-UX.

I added the phrase "on the same hardware" up above to account for the fact
that when a feature appears on a release that is limited to a specific piece
of hardware that feature may not appear on subsequent releases that don't run
on that hardware.  This and the number of different releases is known to be a
big concern for VABs and I am personally hopeful that it will get better.

Despite the qualifications, I hope that customers find HP-UX binary
compatibility to be valuable and worth the effort that we expend maintaining
it.  I consider it to be a significant part of protecting customer
investments.


Eric Hamilton
speaking for myself only