Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: $Revision: 1.6.2.16 $; site datacube.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!datacube!berger
From: berger@datacube.UUCP
Newsgroups: net.micro.68k
Subject: Re: OS-9 and UNIX: Features
Message-ID: <9500007@datacube.UUCP>
Date: Tue, 24-Dec-85 11:51:00 EST
Article-I.D.: datacube.9500007
Posted: Tue Dec 24 11:51:00 1985
Date-Received: Sat, 28-Dec-85 00:24:50 EST
References: <1255@cbdkc1.UUCP>
Lines: 76
Nf-ID: #R:cbdkc1:-125500:datacube:9500007:000:3277
Nf-From: datacube!berger    Dec 24 11:51:00 1985


We are an industrial user of os9 ourselves.  We do all our
development under unix and cross compile to target prom based 68000's
running os9.  This is a very nice hybrid!  

Since most of our  work is  in controlling  image processing hardware
(frame  buffers, real  time signal  processing boards,  etc) Its nice
having  a  target  environment  that does  not have  layers of memory
management and protection.  

Besides not hiding the hardware too much, OS9 has nice  support for C
run-time.  A rather complete stdio library (though I  wish they would
implement  SVID!),  a shell  (we use  it just  to start applications,
maybe Microware could port ksh or csh..), and a symbolic debugger.  

On the other hand, I would feel very cramped if  I was  forced to use
OS9  as  a  development system.   OS9  would be  a better development
environment than  something like  MS-DOS or  CP/M, but  does not have
anywhere near the richness  of Unix.   I  think the  statement of OS9
being where unix was in the early 70's is  quite valid.   Its elegant
and  simple, but  it lacks  the richness  and robustness  of a modern
unix.  

The one feature it does have over unix though, is dynamic linking of
memory modules and super romablity.

The  dynamic  linking  feature  allows  the  user  to create function
libraries that can be  romed.   For instance,  microware supplies the
standard io library in this form.   You link  only the  hooks in your
application code, then at runtime, your application code is linked to
the  standard  i/o  library.   Thus  your executables  don't all need
redundant copies of the  stdio or  math library.   The  user can also
create custom libraries as well.  

Executable modules do not need to know absolute starting locations as
well.   You can  prom an  executable module  and put  it at arbitrary
addresses.    OS9  figures out  where things  are at  startup and the
executables  resolve  globals  and such  at run  time.   This is very
convienent for building custom systems.  

OS9  automatically  supports the  initialization of  static memory at
runtime as well.  

All in all this makes a lovely target prom environment!  Microware is
constantly upgrading their C compiler.   Their main  C guy  is on the
ANSI C committe and they plan to meet the ANSI C specs.  

The things I would wish for are:
* An SVID compatability library. OS9 uses completly non unix
  "ioctl" calls for controling terminals, etc (Its not even called
   ioctl)

* Official support of device drivers being written in C.  (We worked
  it out so we do it anyway.  It would nice to have some more
  official support (documentation)

* Networking that linked to Unix (TCP/IP, NFS, etc)

* A real high level "C" symbolic debugger (dbx?)

* Windows standards (This is not an os9 problem but an industry wide
  problem!)

* Official Microware support of other hosts.  They currently
  only support Vaxen (VMS and Unix).  I'd like to see IBM PC's
  (Not because I like them, just because they are all over the
  place!). Sun's and Apolo's, etc. (We've got it on our Pyramid
  but that was a special)

			Bob Berger 

Datacube Inc. 4 Dearborn Rd. Peabody, Ma 01960 	617-535-6644
	
ihnp4!datacube!berger
decvax!cca!mirror!datacube!berger
{mit-eddie,cyb0vax}!mirror!datacube!berger