Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!pacbell.com!ucsd!sdcc6!jclark
From: jclark@sdcc6.ucsd.edu (John Clark)
Newsgroups: comp.os.os9
Subject: Re: Request for info regarding OS9 on PT68K
Keywords: pt68k
Message-ID: <16430@sdcc6.ucsd.edu>
Date: 6 Feb 91 23:11:32 GMT
References: <11515@helios.TAMU.EDU>
Organization: University of California, San Diego
Lines: 71

In article <11515@helios.TAMU.EDU> n138ct@tamuts.tamu.edu (Brent Burton) writes:
+   How similar to UNIX is it?

When saying similar or non-similar at what level are you talking
about? User or OS. At the user level there are some similarities in
that 1) command shell interpretes commands and exec's subtasks 2)
piped output into input of a sequence of tasks 3) a 'unix'-like C
library function set. Many vanilla functions are implemented.

+   Can you easily port UNIX programs?

With many programs the 'porting' is trivial. But if your unix
program has a 'fork' or similar function call, your 'forked'. The
two OS'es have completely and incompatible sub-task spawning
methods. Other problematic popular unix calles are 'ioctl' and
'select'(Read the networking document for a 'humorous' explanation
as to why that function is conspicuously absent(v1.0,1.1)).

If you are porting networking code direct from a BSD machine then
you will have some amount of either re-write of the code or
implement the appropriate 'ioctl' and 'select' functions.

+      Typically, what changes the most? (I/O, I guess?)

'read,write,open,close' are esstentially the same in terms of
semantics. The big problem here is the use of Carriage Return to
terminate end of text lines, vs. unix Line Feed. If the code is
re-compiled and '\n' are used always for NEWLINE then all is well
but if there is the use of 0x0A or the like then problems are ahead.
The place were this might come up is in bringing 'lex' or 'yacc'
produced files from a 'unix' environment where the table entries for
the parser a have been incoded into system dependent numbers. Again
if you get 'bison' and 'flex', 'yacc' and 'lex' equivalents for OS9
available in some archives then re-yacc and re-lex the source files
and that problem is solved.

+   What type of development tools does it come with(besides C)?

See sales lit.

+   How large is the complete OS on the hard drive?

2-3 meg.
+   Source available?

A driver pack is available as well as a 'port' pack for retargeting
or writing new drivers. As far as I know no source for the kernel is
available unless there's a large charge.

+   Are modifications to the kernel allowed? (by relinking, etc)

New system calls may be introduced by some mechanism which I cann't
recall how now. My main reason for buying any OS is it solves most
if not all my problems and any 'enhancments' can be done in a 'driver'
or similar level piece of code.

Why buy the the thing if you immediately have to 'hack' it to work
right. Build your own or buy another. 

The main features in my mind for OS9 are
1) cheap development system and reasonable Real-Timeness(what ever
that means to you)
2) 90% of the OS and supplimentary packages(ETHERNET,NFS,etc) solve
your OS needs. The other 9 percent is do-able as a driver. The last
1 percent probably is not worth doing for the effort put in and the
benefit gotten out.

-- 

John Clark
jclark@ucsd.edu