Path: utzoo!attcan!uunet!fernwood!decwrl!wuarchive!zaphod.mps.ohio-state.edu!think!snorkelwacker!ira.uka.de!Weimar.Berkeley.EDU!Grunwald
From: Grunwald@Weimar.Berkeley.EDU (Grunwald Betr. Tichy)
Newsgroups: comp.os.os9
Subject: Re: Err. 217
Message-ID: <1373@iraun1.ira.uka.de>
Date: 12 Jan 90 10:08:56 GMT
References: <1450@mcrware.UUCP> <1123100003@stasys> <5936@sdcc6.ucsd.edu>
Sender: root@ira.uka.de
Distribution: comp
Lines: 37

The OS9000 RBF looks fine, but there are some changes i would like to hear of.
First the segment list should be extended by a segment and not a block, because
a segment has much more space.

The access attribute interpretation should be changed.
It is now possible to have a file with owner access denied and public access
allowed. This silly combination should be changed to group access for full
UNIX compatibility in that field and beside of that it is a nice feature. The change will have no effect to the rest of us, because the combination is not used.

The group/user code should be changed to full 16+16 Bits. This change will affect
a lot of utilities and should be therefore announced early, to give programmers
time to prepare for the change.

The Filemanager should be able to use the elevator strategie on devices with the
elevator attribute. The elevator strategie is, to serve all accesses in one direction first, before the direction is changed. As the RBF has an access queue
for any driver, this should be entirely possible. For very special realtime
tasks you can switch back to the first-come-first-serviced strategie we have now.

Another extension i would like is to have the possibility of an access check
program. This is a program which gets the path, group, user and at least one
extra parameter and returns 1 for permission allowed and 0 for permission denied.
The name of the program and the extra parameter should be stored in
the file-descriptor sector. You can have very precise access conditions with that feature. (example: game access only outside of working hours, extra passwords for
special files (personal files, which have to be protected)).

I like OS9 a lot and would be glad over any improvement, but microware should think of changed marketing strategie. With the high prices on any product you
have not enough enthusiast, which do the dirty work of nice utilities, which are
not to hard to program, but very time intensive.

Also i would like to see microware to contact independent developers like
Heimsoeth and Borland to port their products to OS9. Especially Turbo-C i
much better for normal programs as the microemacs, than Microware C V3.0 that
i have. The microware C-Compiler has the actual OS9-libs, but thats not enough
now.

I hope the thinks are getting better and microware will answer. I think lots of
people will await this answer to.