Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!sci.ccny.cuny.edu!phri!cmcl2!esquire!jenkins
From: jenkins@esquire.UUCP (Colin Jenkins)
Newsgroups: comp.sys.pyramid
Subject: Re: Any compatibility issues between Pyramid systems?
Message-ID: <1871@esquire.UUCP>
Date: 22 Mar 90 03:16:45 GMT
References: <6707@brspyr1.BRS.Com>
Reply-To: jenkins@esquire.UUCP (Colin Jenkins)
Organization: DP&W, New York, NY
Lines: 49

In article <6707@brspyr1.BRS.Com> tim@brspyr1.BRS.Com (Tim Northrup) writes:
>Does anyone know if there are any compatibility issues between Pyramid
>models? [...] is there anything that we would generate on that box that
>would not work on any other Pyramid system (MIServer, 9040, etc.)?
> 
>We do all of our work in C, currently in the att universe under OSx 4.4c.

We have 98x's running 4.1 and MIServers running 5.0.  We do almost all of
our work in the bsd universe.  Our exprerience is that most binaries will
run on both OSx versions.  There are definite incompatibilities however.  We
have a ksh (probably) compiled on 4.0 that works fine on OSx5.0 *except*
under X windows.  A recompile seems to fix the problem.  Any low level "ps"
type programs (that read kernel structures) probably won't work.  Any 
program that tries to read /dev/drum will not work on OSx5.0.  Since tty 
names have changed in OSx5.0, OSx4.x programs that have tty names hard 
coded into them will break.  The format of device numbers has changed 
between versions as well, however I know of no specific examples of binaries 
breaking for this reason.  I know of at least one OSx2.5 binary that ran 
fine on OSx4.x but not on OSx5.0.

I believe that OSx5.0 supports dynamic sizing of open file descriptor tables,
OSx4.x does not.  A process hoping to open a few hundred file descriptors
on a 4.x system will be disapointed (yes, they do exist...).

Signals between 4.1 and 5.0 have changed- under OSx4.1, SIGLOST is 31, but
under OSx5.0, SIGLOST=SIGURG, and signal 31 is SIGWINCH.  I would guess that
4.1 binaries looking for SIGLOST on a 5.0 system would be looking for window
size change signals erroneously and acting on them incorrectly.

In addition, OSx5.0 adds at least one more system call (perhaps) more, and 
running 5.0 binaries on lower releases is not something I'd recommend.

Also, there are bug fixes in the OSx5.0 libraries that may not have made it
into your 4.x libraries.  If you don't recompile your programs for OSx5.0,
you may be running with 4.x library bugs on the 5.0 system.

My advice is to recompile for both systems and save yourself some potential
headaches.  Even when something appears to be running well on both systems,
you may find some special situation that causes a failure as we have with
our ksh under X windows (as one example).  If you must mix binaries, don't
do it downward (don't run 5.0 binaries on 4.x, run 4.x on 5.0).


						Colin

						jenkins@dpw.com
						jenkins@cs.purdue.edu
						uunet!esquire!jenkins
						cmcl2!esquire!jenkins