Path: utzoo!attcan!uunet!mcrware!davely From: davely@mcrware.UUCP (Dave Lyons) Newsgroups: comp.os.os9 Subject: Re: Err. 217 Message-ID: <1474@mcrware.UUCP> Date: 13 Jan 90 18:31:32 GMT References: <1450@mcrware.UUCP> <1123100003@stasys> <5936@sdcc6.ucsd.edu> <1373@iraun1.ira.uka.de> Reply-To: davely@mcrware.UUCP (Dave Lyons) Distribution: comp Organization: Microware Systems Corp., Des Moines, Iowa Lines: 71 In article <1373@iraun1.ira.uka.de> Grunwald@Weimar.Berkeley.EDU (Grunwald Betr. Tichy) writes: +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. I'm not exactly sure what you mean by this but let me explain the way it works and then you can point out where you see the deficiencies. With OS-9000 RBF, when the segment list in the first file descriptor block fills up, RBF allo- cates another block. The new block is linked to the first one by LSN "poin- ters" kept in the last segment entry. Segment lists don't fill up that often so I think just expanding the list by a block at a time is the most effecient way to go. +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. As far as file attributes go, the field is now 16 bits and there are now bits for group access and the permission rules have been changed as you have men- tioned above, i.e. public access allows group and owner access also. +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. I think something like this will definitely be implemented for OS-9000. +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)). This is an interesting idea. +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 is +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. Oops, these sound like marketing questions. I hope this tells you some of what you wanted to know. Dave -- Dave "Not the Apple Guy" Lyons - uunet!mcrware!davely ---------------------------------------------------------------------------- "We can't possibly fight you. We're totally weak." - Bill S. Preston, Esq. My employer laughs at my opinions.