Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!dlyons
From: dlyons@Apple.COM (David A. Lyons)
Newsgroups: comp.sys.apple2
Subject: GS/OS Close(0)
Message-ID: <51058@apple.Apple.COM>
Date: 2 Apr 91 15:39:06 GMT
References: <156810@tiger.oxy.edu> <13207@ucrmath.ucr.edu> <1991Apr2.070426.23818@nntp-server.caltech.edu>
Organization: Apple Computer Inc., Cupertino, CA
Lines: 33

In article <1991Apr2.070426.23818@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes:
>[...]
>I can't answer for the french guys, but I have thought about this one. All
>you need to do is apply the UserID matching criteria that the Memory Manager
>uses for DisposeAll() calls. Close calls with refnum's of 0 are extremely
>rare anyways, because of the lack of UserID protection.
>
>The UserID system and certain hooks in the system designed solely for
>MultiFinder-type switching have existed since day 1; The last barrier to
>a real switcher is GS/OS itself. It is rumored that the next version of GS/OS
>will allow proper context switching and so on, in order to make cooperative
>multitasking possible.
>
>Todd Whitesel
>toddpw @ tybalt.caltech.edu

I'm missing something:  What do memory manager User IDs have to do with
GS/OS Close(0) calls?  If you're proposing that GS/OS associate a User ID
with every file reference number, that's an interesting idea, but a
"MultiFinder" could do that itself, just by intercepting Open and Close
GS/OS calls.

The UserID system has plenty of value other than for MF-type switching;
several parts of the *toolbox* are a much bigger barrier barrier to a
MF than GS/OS is.
-- 
David A. Lyons, Apple Computer, Inc.      |   DAL Systems
Apple II System Software Engineer         |   P.O. Box 875
America Online: Dave Lyons                |   Cupertino, CA 95015-0875
GEnie: D.LYONS2 or DAVE.LYONS         CompuServe: 72177,3233
Internet/BITNET:  dlyons@apple.com    UUCP:  ...!ames!apple!dlyons
   
My opinions are my own, not Apple's.