Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!apple!portal!motcad!jtc
From: jtc@motcad.portal.com (J.T. Conklin)
Newsgroups: comp.sys.m88k
Subject: Re: Open Hardware
Message-ID: <1991Apr26.184514.21951@motcad.portal.com>
Date: 26 Apr 91 18:45:14 GMT
References: <16@metran.UUCP>
Organization: Computer Signal Corp., San Ramon, California
Lines: 50

In article <16@metran.UUCP> jay@metran.UUCP (Jay Ts) writes:
>A few days ago, I referred to the recently-formed ACE alliance, made up
>of such industry heavyweights as DEC, SCO, Microsoft, MIPS and Compaq.
>The group is planning to form standards for the MIPS RISC architecture
>similar to what 88open has been doing for the 88k, but with some major
>differences.  This got me thinking, so I posted a question:  "Does 88open
>define a hardware standard that would allow a company to develop a UNIX
>port to run unmodified on all 88open-compliant machines?"
>
>The answer is: "No."  A few of those who replied to my post went on to
>explain that 88open's standards applied to software only -- the interface
>between third party software and the operating system.

I don't know if this is true.  I am able to run binaries compiled on a
Motorola MPC on a DG Aviion and binaries compiled on the Avvion in the
m88kbcs development environment.

In fact, I used the Aviion almost exclusively to generate binaries for 
the MPC since Motorola's development tools are hideous.  In fact, 
software written to the BCS/OCS standard will not necessarily compile
on the MPC.  For example, in /usr/include/string.h:

    /*
     * OCS says to typedef size_t here.  That causes too many problems
     * for folks wanting to include sys/types.h.
     *
     * typedef unsigned int size_t;
     *
     */

Rather than protecting the typedef with the standard practice of #ifndef's
and #defines.  Motorola decided to ignore OCS and not define size_t.
It takes a lot of header file editing to make a usable Motorola MPC.

Back to the Aviion.  It does a great job -- but it could be made a lot
better.  For example, it supplies the core OCS/BCS libraries in the
m88kbcs environment, but not the BCS networking supplement.  Since the
product I am working on uses a network license server, I had to go 
back to the MPC :-(.  If DG supplied these libraries, I wouldn't have
to touch a MPC again :-).


Getting back to the subject.  As far as I know, BCS binaries should run
on any 88open BCS complient box.  But it is very easy for a application
to step over the bounds of BCS and become dependant on machine or 
vendor specific feature.  You should have no problems if you are 
careful.

-- 
J.T. Conklin    jtc@motcad.portal.com, ...!portal!motcad!jtc