dlyons@Apple.COM (David A. Lyons) (04/02/91)
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.
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (04/03/91)
dlyons@Apple.COM (David A. Lyons) writes: >I'm missing something: What do memory manager User IDs have to do with >GS/OS Close(0) calls? We want to prevent a Close(0) from closing files that the application didn't open!! Suppose we have some sort of multifinder environment up. An NDA or application opens a file while another application (say APW or ORCA) is using a shell application, and the file level is hiked up so the shell application's files can be closed when it quits -- by a Close(0) from the controlling program. Under the current system, with no UserID tags on open files (GS/OS should have used UserID tags from the start; the TOOLBOX should have used UserID tags far more extensively than it does) when that Close(0) is executed by the shell all files opened at the current level or above get closed, INCLUDING the files opened by the NDAs or other applications. Not good. > 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. True. I however think it would be MUCH cleaner if a process manager were implemented in GS/OS itself. The alternative is to have a multifinder that has to save and restore ALL the prefixes (blech!) when it would be better to have GS/OS support saving and restoring the current application. The Resource Manager does it properly, why can't GS/OS? >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. That's not obvious to me from my readings of the toolbox manual. If anything the GS toolbox is better designed to make the move to a multi-application environment than the Mac toolbox was. The real problem is in arbitrating resource use between applications -- patching the tool locator to use UserID's uniformly for keeping track of who started what is not too bad, but points out a fundamental flaw in the toolbox itself -- the UserID is not enforced well enough and the initial application guidelines left plenty of room for making program switchers difficult. Programs that work with the current version of the operating system are better equipped to deal with the changes that will be necessary. I think it is important that the tool and O/S teams at Apple give some serious thought to this problem -- the future is ALWAYS more important than the past and I am willing to bet that most of the applications people really care about will still work with a toolbox and O/S modified to properly support multitasking. In the end, it's grow or die. Todd Whitesel toddpw @ tybalt.caltech.edu
dlyons@Apple.COM (David A. Lyons) (04/04/91)
In article <1991Apr3.025718.5615@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >We want to prevent a Close(0) from closing files that the application didn't >open!! Yes, I understand the problem. I was trying to say that tagging the files according to "who opened them" is the boring part of the problem, whether it's done by GS/OS internally or by a tack-on MultiFinder that intercepts GS/OS calls. The *interesting* part, given that there is no explicit concept of the "current application" (no "GetCurrentOSApp" and "SetCurrentOSApp" calls) is determining on the fly what application to tag a file with. If you're thinking it would call FindHandle on the address the OS call is being made from & check the user ID of that block, then I ask: o What about files opened by the toolbox *on behalf of* an application or DA? o What about files opened by the Loader, ExpressLoad, or GQuit? DAL>The UserID system has plenty of value other than for MF-type switching; DAL>several parts of the *toolbox* are a much bigger barrier barrier to a DAL>MF than GS/OS is. >That's not obvious to me from my readings of the toolbox manual. If anything >the GS toolbox is better designed to make the move to a multi-application >environment than the Mac toolbox was. The real problem is in arbitrating >resource use between applications -- patching the tool locator to use UserID's >uniformly for keeping track of who started what is not too bad, but points out >a fundamental flaw in the toolbox itself -- the UserID is not enforced well >enough and the initial application guidelines left plenty of room for making >program switchers difficult. Every time anybody makes calls to DisposeAll, SetPurgeAll, HLockAll, or HUnlockAll (which operate on all handles owned by a given user ID), the user ID system has value. The Loader and ExpressLoad use some of these. User IDs are also invaluable when doing any debugging, since they let you see what's where. Patching the tool locator to see who started what--do you mean watching for xxxStartUp and xxxShutDown calls and not *really* shutting down a tool until everybody who started it up has shut it down? -- Biggest problem with that is that NDAs traditionally (and rightly) check to see if a tool is already started; if it is, they use it *without* starting it up again. >[...] >Todd Whitesel >toddpw @ tybalt.caltech.edu -- 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.
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (04/04/91)
dlyons@Apple.COM (David A. Lyons) writes: >The *interesting* part, given that there is no explicit concept of the >"current application" (no "GetCurrentOSApp" and "SetCurrentOSApp" calls) >is determining on the fly what application to tag a file with. I don't consider determining-on-the-fly a viable option, for exactly the reasons you gave. To make a multifinder work, the O/S _MUST_ have Set & Get calls to inform it when the current process changes. This is why I think the facility should be built into GS/OS -- we will be patching the hell out of the system already in order to insure that GS/OS and the tools are informed when the CurrentOSApp changes. Dave, we've heard too much of "kludging it in won't work because of THIS" -- we're not interested in kludges. We want to know if the software teams can add something to the system itself, so third parties won't have to waste memory and execution time forcing the present system to do it. Todd Whitesel toddpw @ tybalt.caltech.edu
dlyons@Apple.COM (David A. Lyons) (04/06/91)
In article <1991Apr3.222202.15461@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes: >[...] >To make a multifinder work, the O/S _MUST_ have Set & Get calls to inform >it when the current process changes. This is why I think the facility should >be built into GS/OS -- we will be patching the hell out of the system already >in order to insure that GS/OS and the tools are informed when the CurrentOSApp >changes. Whether it's in the OS or somewhere else, the $65,536 question is how to *make* all of the Get/SetCurrentOSApp calls at the right times. If any of them have to be made by the applications, that's a problem. >Dave, we've heard too much of "kludging it in won't work because of THIS" -- >we're not interested in kludges. We want to know if the software teams can >add something to the system itself, so third parties won't have to waste >memory and execution time forcing the present system to do it. I didn't mean to come across as "it will never work, here's why." I pointed out some tricky problems that would need to be dealt with. If all of them turn out to be solveable, great. "Kludginess" does not bother me in itself, as long as I have a detailed understanding of the interactions going on & the conditions under which it will work. -- 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.
toddpw@nntp-server.caltech.edu (Todd P. Whitesel) (04/06/91)
dlyons@Apple.COM (David A. Lyons) writes: >Whether it's in the OS or somewhere else, the $65,536 question is how to >*make* all of the Get/SetCurrentOSApp calls at the right times. If any of >them have to be made by the applications, that's a problem. Very true. I have faith (ouch) that only the 'MultiFinder' code and the tools that it patches (or the tools themselves, if Apple would like to give us any help on this) will need to make those calls. >I didn't mean to come across as "it will never work, here's why." I pointed >out some tricky problems that would need to be dealt with. If all of them >turn out to be solveable, great. "Kludginess" does not bother me in itself, >as long as I have a detailed understanding of the interactions going on & >the conditions under which it will work. Ok. I was mostly trying to express the frustration that builds up when every idea we come up with for third party 'something' appears to be shot down by DTS because of the way the current system is set up. After a while it feels like DTS is trying to discourage third party development of 'something'. It now occurs to me that maybe it's because Apple is already working on it, and you don't want third parties to feel shafted?? (hope, hope) As for Kludginess, it is something to be avoided at all costs, or done so well that no more kludges will be needed. Nearly everything new about system 5.0 (and GS/OS itself) qualifies as the latter, and that's why I like it more than any other O/S I am familiar with. However, closed-form kludges that force you to kludge around THEM later on can kill a developing system very fast because the object gets bigger and the design gets so messy nobody can put up with it. This entropy effect has happened to a couple medium size programs of mine, so I think I know what I'm talking about -- the GS system software is a lot bigger and many programs depend on it, so that effect should be far more dangerous. Todd Whitesel toddpw @ tybalt.caltech.edu P.S. Dave, thanks for taking the driver question, I really don't want to spend days crashing the system until I guess right. I'll also need to register two supervisor ID's sooner or later...