ABIs and the futurrrr of UNIX(tm)

[David L. Smith]

In article <587 at garth.UUCP>, walter at garth.UUCP (Walter Bays) writes:
> In article <185 at tscs.UUCP> gerard at tscs.UUCP (Stephen M. Gerard) writes:
[ A call for a psuedo-code machine independent binary standard ]
> 
> The idea sounds very good.  But perhaps you can explain why it's so
> hard for a developer to provide multiple versions.  (This is not a
> knock at developers; I simply don't know the answer.) If we believe in
> source code standardization, all you have to do is recompile.  (Right?
> :-) Is the problem access to the various machines to do the port?

Well, there are enough problems just porting across machines and slightly
different version of Unix.  For example, today I started work on porting
some code from our ancient Parallel which runs an old release of SunOS to
our nifty, new ICON system.  Hardware-wise, the ICON is very nice, but their
implementation of UNIX has a few weird quirks, due to their hybridization
of BSD and Sys V.

At the heart of my code is a set of database routines that use flock() and
lockf() calls to keep things in order.  On SunOS lockf() has an enforced
mode, where the kernel will make routines that attempt to read/write a
locked section block until it is unlocked.  ICON choose to implement the
Sys V version instead which does not have an enforcement mode.  Since I was
depending on this enforcement in a few parts, I had to rewrite the routines
so that they do a check for locks before read/writing.  I had also fortunately 
encapsulated read/writes to the database into a few routines which I could 
modify easily.  However, if I had not and I had several thousand read/write 
statements into this database which depended upon enforcement it would be a 
serious problem, requiring quite a bit of man-power to track down and fix.  

This is not a _major_ problem and the port is going rather smoothly, but
this is just between two 680x0 based machines, both running BSD derivatives.
In fact, I could have taken my SunOS binaries over to the ICON and waved
a magic program over them and had them run on the ICON.  Had I done this,
however, the enforcement mode would not have worked and I would have ended
up with one royally screwed-up database with no clue as to how it got that
way.

The psuedo-code idea is nice, but I'd settle for full source code compatibility.
However, the only way to get this is to buy an identical machine with 
identical software and one of the reasons we all like Unix so much
is that it runs on so many different pieces of hardware supported by so many
different vendor.  If each vendor were to implement "standard" Unix and only
"standard" Unix, what would be the point of having different vendors?  However,
with different vendor extensions the only way to write portable code is to
write to the minimal standard, which defeats the purpose of having extensions.

What's my point?  We cannot have "standard" Unix running on "standard" hardware
unless we are willing to accept stagnation.  View the microcomputer marketplace.
It is standardized around the IBM PC/MS-DOS standard and has been _stuck_ there
for four years without significant change.  "Standard" Unix and hardware
standardized around SPARC will force the same stagnation upon the Unix and
mini-computer market.  In order for us to have new and niftier products to
play with, we must accept the burdens that come with new and different things;
namely some hard work in getting them working.  Unix, as of 1988, is not the
ultimate in operating systems.  What AT&T and Sun will produce will not be
either.  I hope what I will be working on in the year 2000 will be significantly
different from what I'm working on today, however I doubt it.  We seem to
be narrowing in on a peak for computers which will not substantially change
for some time.

(Sorry for the soapbox, but I needed to say it)
-- 
David L. Smith
{sdcsvax!jack,ihnp4!jack, hp-sdd!crash, pyramid, uport}!sdeggo!dave
sdeggo!dave at amos.ling.edu 
Sinners can repent, but stupid is forever.