[comp.os.os9] OS-9 Discussions, V3 #4

os9@cbdkc1.UUCP (05/20/87)

OS-9 Discussions         Tuesday, May 19th 1987         Volume 3 : Issue 4

Today's Topics:

                      More on SELECT bug, bidirectional IO
                             Which BBS's support OS9?
                                 Uuencode/decode
                         Patch for RS C compiler.  MOTD?
                             OS/9 and Unix/UniPlus+

[Moderator's Notes:
 First, after the upgrades to my system and other problems, we had a quickly
 implemented change of machines feeding cbdkc1.  Anyone using a path through
 cbatt should immediately change to cbosgd.  If you have tried to submit
 articles and haven't seen them posted, keep trying or send me a copy by way
 of cbosgd!cbdkc1!daleske.  Which brings us to the second point;  You should
 now be able to write articles directly to comp.os.os9 which will be auto-
 matically forwarded by your nearest backbone.  Your submissions will be
 mailed, assuming that your news administrator has set things up correctly.
 - JDD]
--------------------------------------------------------------------------

Date: 11 May 87 21:44:46 GMT
From: knudsen@ihwpt.ATT.COM (mike knudsen)
Subject: More on SELECT bug, bidirectional IO

Keywords: Mental block,both ways on one path,9-40
Organization: AT&T Bell Laboratories - Naperville, Illinois
Copied from Newsgroup: comp.sys.m6809

[I felt this article had quite a bit of information which may not be
 reaching everyone. - JDD]

Thinking about why I had worked thru that notorious BASIC09
example (page 9-40, SELECT) a dozen times and never figured
out myself what the error was, I finally found my mental
block.  Maybe you'd like to be warned about this.

Hanging around UN*X, OS9, and Pipes leads you to think
that input comes in over here and output goes out over there.
That is, you have StdIn and StdOut and never the twain shall
meet.  I would get real nervous contemplating the idea of
reading and writing over the same path--that ain't OS9,
hell it isn't even RS-BASIC!  And might not terrible things
happen when the bytes collide in the middle of the buffer?
Won't the buffer get confused?  Turns out all these fears
are unfounded, but they kept me from seeing the solution.
	These fears also made me wonder about the new
"<>>>" and related redirects in the Level 2 Shell.
Could they really mean what they said?
	I recall getting confused in some BASIC09 code about
whether stdin and stdout were really separate, or both on
path #1.  I think they are paths #0 and #1, just as in "real"
OS9 programs (C, assembler) and UN*X programs.
	However, once you open a device window and SELECT it,
the manual flatly states that "it becomes THE interactive
window."  In other words, BOTH input and output (keys and
screen) are thru the same path # you got when OPENing the
window before SELECTing it.  This statement must have clued
someone in as to where the program example's errors were.
	So that's why it must be OPENed in UPDATE mode.
And why the INPUT or GET or INKEY$ must be done on that
OPENed path#, not on stdin (and why did the example use #1
instead of #0, or is that right?)
	So there it is--you can have In and Out thru the
same path # to an SCF device, if OPENed with UPDATE.
Hey, them OS9 buffer managers in SCFMan are pretty smart.
Should work for RS232 and modems too.  Good riddance to another
mental block.
-- 
Mike J Knudsen    ...ihnp4!ihwpt!knudsen  Bell Labs(AT&T)
    Delphi: RAGTIMER    CIS: <memory failure, too many digits>
		"Just say NO to MS-DOS!"

Date: 14 May 87 14:43:41 CDT (Thu)
------------------------------
 
From: ihnp4!ihwpt!knudsen
Subject:  Which BBS's support OS9?

[I asked Mike Knudsen which BBS's he felt supported OS9.
Which alternate BBS's do you use and find useful?  Which
supports OS9 the best? - JDD]

Of the commercial big-bull-boards, I think Compuserve and
Delphi are the only ones worth considering.  Compuserve
(CIS) is the oldest and still has a very active OS9 SIG
on it, tho I haven't checked in lately.  Also, I found out
that OS9-related postings from comp.sys.m6809 are being
copied and reposted on CIS.  One guy who uses both CIS and
Delphi sent me Delphi mail saying "Oh, you're the same guy
as knudsen!  Been reading all your stuff, etc."
Myself, I haven't checked into CIS lately tho I have a login;
been too busy with Delphi.

Delphi has the advantage of being cheaper (especially at 1200
baud, no surcharge), and being officially supported by
Rainbow magazine.  All the Rainbow editors and staffers are
on Delphi almost every night, including Kevin Darling,
Steve Bjork, and Marty Goodman.  (Of course CIS has its heavy
hitters too, like Pete Lyall and others.)
Like CIS, Delphi has an OS9 group that is a subgroup of
the Coco SIG (on CIS OS9 may still be totally separate;
the point is that both systems have an OS9-only group).

BIX you don't want, not till BYTE discovers OS9 at least.
The Well I know nothing about.

I say go with established winners that already recognize OS9,
and don't split the world up any more than it already is between
CIS and Delphi.  These opinions are of course all mine.
Why don't you poll the group and see?

PS: Since most of our group is Canadian, we should ask
which of the two BBS (CIS or Delphi) has the best/cheapest
access from there.

	mike k

Date: 16 May 87 05:18:06 GMT
------------------------------
 
From: jimomura@lsuc.UUCP (Jim Omura)
Subject: Uuencode/decode

Organization: Consultant, Toronto
Copied from Article 226 of comp.sys.m6809:

     Mark!  Bad timing man!  I ported a Uuencode and Uudecode to OSK
a few days ago.  I ported a DRI C version and it compiled without any
changes in the Uudecode and only 2 small changed in the Uuencode.
I thought about posting it but changed my mind.  I expect that they
would have compiled equally under 6809 C.  Oh well.

     In case anyone is interested, on BIX we've got the following work
in progress:

1.  Modified Lempel-Ziv Compress (same 'compress' as on most Unix systems).
    I got this to work on small text files.  It died on object code and
    on large text files.  I have no further time to debug it.  If someone
    else wants to finish it I'll send it via mail.

2.  ARC has been ported by a fellow in Germany.  I'm awaiting a copy and
    I'll get in touch with Software Enhancements for their approval to
    post it to BIX when it arrives.  I'll also ask about the Net.

3.  SDB.  The Users' Group has a port of this apparently, but I didn't find
    out until after I'd started my own port.  I don't know what version
    the Users' Group has, so I may finish this port.  Someone else on
    BIX may finish it anyway.  There didn't seem to be much to do.

4.  Proff.  I looked at the code, shook my head and said "not right now".
    I like 'proff'.  It doesn't look all that portable though.  Not after
    I started really looking at it.

5.  KB (Knowledge Base)  Same problems as Proff.  I've halted work on it
    for now.  These two programs seem too difficult for me to do at my
    current level of experience.  Maybe later.

6.  'Profit' is one of those weird deals where the author has requested
    that you don't post ported versions.  It's easy enough to port, but
     you have to get the sources from the author ($5.00 or so).  Did I
     say Profit?  Wrong program.  I meant 'Planit'.

7.  I've just begun a rough spec for a calendar/datebook.  I'm also looking
    to see if someone else has written one I like.  I don't want to write
    one if I can avoid it, but it's starting to look necessary.

     These are most of the current public domain things I'm involved in
one way or the other (and other members of BIX).  As a commercial enterprise,
someone on BIX is porting X-Windows to a high performance OS-9 machine
with ACRTC support, but that has nothing to do with the conference directly.
We're looking forward to his/their report though.

     I'm glad to hear that someone is working on Uuslave.  I've seen the
sources for Uuslave and Uuclone and I don't like the looks of either.
They both seem to have substantial portions of machine code which may
just amount to drivers, but may cause problems.  Good luck to him/them(?)!!

Cheers! -- Jim O.
-- 
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura

Date: Sun, 17 May 87 15:20:43 EDT
------------------------------
 
From: jimomura@lsuc.UUCP (Jim Omura)
Subject: Patch for RS C compiler.  MOTD?

Summary: Patch request
Organization: Consultant, Toronto

     A long time ago Dale Puckett published a patch for the Radio Shack
version of the C compiler to run it on a Hard Disk.  Since I've moved, I
no longer have any semblance of organization for my magazine collection
and I can't find it.  Does anybody know what the patch was?

     The crux of the problem is that the C compiler looks to /d1 to find
DEFS and LIB directories.  In fact, what I want to do is have the
compiler look to /dd, thus making it easy to use on whatever hard
configuration I'm using.
-- 
Jim Omura, 2A King George's Drive, Toronto, (416) 652-3880
ihnp4!utzoo!lsuc!jimomura
Byte Information eXchange: jimomura

Date: 19 May 87 12:25:56 GMT
------------------------------
 
From: Nigel Horne <njh@root.co.uk>
Subject: OS/9 and Unix/UniPlus+

Keywords: comparison
Organization: Root Computers Ltd., London, England

Does anyone have a (preferably objective) comparison between
OS/9 (release 2.0 I guess) and UniPlus+/Unix?

I'd rather not have flames/really subjective NIH attitudes,
just *facts* to allow me to compare.

If enough interest is generated I'll post, of course.

[Actually, I'll post them if you forward them to me, Nigel. - JDD]

-Nigel
-- 
Nigel Horne, Divisional Director, Root Technical Systems.
<njh@root.co.uk>	G1ITH	Fax:	(01) 726 8158
Phone:	+44 1 606 7799 Telex:	885995 ROOT G	BT Gold: CQQ173

[ How does one answer this in fewer than N digests where N is large?
There are so many factors involved.  I suppose one approach would be
to ask what your needs and interests are.  That would help focus the
discussion.  In addition, I will forward some of the digests which
have covered portions of your question.

In general, there are currently, two main versions of OS/9;  Both are
machine specific;  The original being the 6809 and the more recent version
being for the 680XX line of microprocessors.  The single largest installed
base for OS/9 systems is probably real-time process controls.  I understand
there are over one million micros running OS/9.  In addition, there are a
number of manufacturers of systems which are used for many other purposes.
I believe that there are some companies in the UK who sell OS/9 based systems.
One is embedded in an add-on disk for one popular system, such that when you
plug in the disk, the system boots OS/9.

Is OS/9 a UNIX system?  No.

Is OS/9 a UNIX-like system.  Yes, as are MINIX, QNX, etc.  There are many
versions of UNIX, 4.2, System V, etc. all of which have different feature
sets.  The feature set of OS/9 compares favorably with many UNIX installations.
My personal favorite features are its module-based structure and shared
libraries!  I have never worked on another system where I could develop
and debug new versions of device drivers while using the current versions
and all without sources for any of the kernel other than the device drivers
that I was developing.

Will OS/9 replace UNIX?  Probably not.  Each has a place of imporatance
in the future of computing.  Recently, I read a description of OS/9 as
"OS/9 is UNIX on a CP/M budget."  I use UNIX systems all day long, all
requiring (large) hard disks and lots of memory.  When I go home, I use
my self-ported OS/9 68K system with two 8" floppies (1.2M each) and a total
of 256K available to the 68000.  I can run a compile in the background and
be editting at the same time with that configuration with some memory to
spare.  This example pales when you look at a Radio Shack Color Computer
running multiple windows with each of the jobs updating the screen.  I saw
a Fujitsu with two 6809s, one running as a front-end I/O processor, that
had four screens running the same, complex graphics demo.  Each demo was
producing a large number of display changes.  The system did not appear any
slower as each window was created and started.

UNIX runs on so many machines from medium-sized to Cray X-MPs.  You will not
find it on systems which can easily run OS/9.  There exists quite an overlap
in that center ground where your comparison will need to distinguish the
required features. - JDD]

-------------------------------------
The views expressed in OS-9 Discussions are those of the individual authors
only.  Copies of digests are available by mail request.
------
Moderator:  John Daleske   cbosgd!cbdkc1!daleske    daleske@cbdkc1.ATT.COM
Submissions should go to:  cbosgd!os9               os9@cbosgd.ATT.COM
Comments to the moderator  cbosgd!os9-request       os9-request@cbosgd.ATT.COM

*********************
End of OS-9 Discussions
*********************