Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!pyramid!eric
From: eric@pyramid.pyramid.com (Eric Bergan)
Newsgroups: comp.sys.pyramid
Subject: Re: Makeing "Gated"
Keywords: Gated
Message-ID: <151920@pyramid.pyramid.com>
Date: 14 Apr 91 18:11:08 GMT
References: <671136511.AA15442@flaccid> <151385@pyramid.pyramid.com> <128287@uunet.UU.NET>
Organization: Pyramid Technology Corp., Mountain View, CA
Lines: 124

In article <128287@uunet.UU.NET> rbj@uunet.UU.NET (Root Boy Jim) writes:
>In article <151385@pyramid.pyramid.com> eric@pyramid.pyramid.com (Eric Bergan) writes:
>>	In general, DON'T DO THIS! Cross universe linking can get very messy.
>
>It's only messy because Pyramid made it so. I pulled out the memory
>stuff, getopt, and some string functions from Sequent's ATT libc.a
>and put them in the UCB libc.a because I was tire of dealing with it.
>
>>If you do the above, for instance, you will get the ucb signal
>>semantics. If your program expects the att semantics, then you're in
>>trouble. This is widespread through the libraries - *printf and *scanf
>>have subtle differences, malloc is a different algorithm, etc.
>
>Using the return value from *printf and *scanf is nonportable.
>Even if malloc is different, it should work either way.

	I think we have different views of what portability means. Yes,
the return values for printf and scanf are nonportable across varieties
of UNIX, but that shouldn't make them nonportable between systems claiming
to support the same subspecies of UNIX. malloc's syntax may be common
(well, malloc(0) is a little unclear) but since different time/space
tradeoffs are made, the end result on the suitability of the program that
is built can be dramatic.

	Also, I'm actually less concerned with the library routines than
the system call interfaces. Signal semantics, or tty handling tend to
be much more difficult to port around. Specifics of memory management
also tend to be difficult to blend into a single interface. Or maybe
the semantics of kill() - in one universe you can send signals to
zombies, not in the other. 

	On the otherhand, the back flips necessary to use sockets in
an att universe program, or shared memory in a ucb universe program, are
overly complex. There has always be an item on the "to do" list to
open up universe-exclusive functionality (i.e. functionality not
available in the other universe), but it has always fallen below the line on
the list of features that customers wanted for each new release.

>>	Note that occasionally this will work fine. You might not
>>get bitten. But it is simply wrong in the general case. Even extracting
>>the necessary modules from the other universe's library can be a 
>>problem - you need to check what referenced externals there are, and
>>make sure they won't have problems in the other universe.
>
>Yes, things can get tricky, but if one goes to all the trouble of
>doings so, one should not be thwarted by the vendors.

	How do you view us as thwarting this, if you go to all the
trouble? version.o is a nasty surprise the first time, but can be
pulled across, just like any other module. (I'm assuming you're talking
about building an auxilary library, not linking the routines into
libc.a itself.)

>>	We can get philisophical about whether it was better to stay 
>>strictly compliant with the ucb and att standards, or to blend them
>>together and get something that wouldn't necessarily be compliant
>>with either.
>
>We don't have to get philosophical; the answer is clear. Ten years
>ago dual universes were kinda neat. You could satisfy people
>from both camps on the same machine, and it was a marketing plus.
>
>However, the world is moving towards a merged system. At least
>half of the portability problems I see have to do with the
>index/strchr or memcpy/bcopy dichotomy. Why not supply both?
>
>The att and ucb environments are not so much universes as
>galaxies within the same universe. At one end of the spectrum
>is att, at the other, ucb. Real implementations are somewhere
>in between, with features of both.

	Unfortunately, this is not true of the older releases. Most
of our customers are pretty unhappy that semantics of functions and
system calls vary from vendor to vendor. They want a standard that
everyone abides by. Having vendor-specific decisions about where to
be "in between" makes them very unhappy.

	As I mentioned before, supplying index/strchr, or memcpy/bcopy
are the least of the problems. Much more interesting are the 
customers that want native streams and native sockets, in the same
system.

>If you want a separate universe, make it a VMS one.

	Well, we have talked about SVR4 and OSF/1 (and maybe NT)...

	(The above is a joke, and should in no way be considered a
statement of product direction for Pyramid!!!)

>>Basically its a no win situation - for every customer
>>that would like a blended environment, another would like one
>>where their strictly compliant program would work.
>
>This may have once been true. Better repoll your customers.
>It has been said that there is no such thing as portability,
>only programs that have been ported. Strict compliance
>may also lead to tunnel vision.

	We do, frequently. The dual port is not necessarily fun
to maintain - it would be great to relax some of the strict
implementation issues. But that would break some segment of working
programs, and I don't think the bulk of our customers would appreciate
that. Again, its not the simple items like strchr/index that
concern me as much as the system call semantics that force some
of these issues. 

>>The only true solution
>>is a standard that encorporates both, and that is why we are so
>>active with SVR4.
>
>Well, you had better keep you eye on what Berkeley does too.

	We'll continue to watch what they do, but I think the bsd will
become less of a force in the commercial marketplace. By their own
statements, Berkeley would like to get their releases back to the
research basis that they wanted, to investigate computer science issues,
and not have to worry about 4 zillion vendors calling up to complain
when there is no upward compatibility, or they don't closely track
the latest IEEE standard.

-- 

					eric
					...!pyramid!eric