ericmcg@pnet91.cts.com (Eric Mcgillicuddy) (12/20/90)
>GS/OS is a hell of a lot nicer -- it has the best designed calling conventions >of any O/S (fully extensible parameter lists and such). The main thing I still >want to see done is real process support based on the UserID system. This >would make multifinders a lot easier than the Mac one was, and will make unix >style shells extremely easy to support. > >As a programmer, I feel that O/S research is due for a revolution soon anyway. >Until then, give me GS/OS. > >Todd Whitesel >toddpw @ tybalt.caltech.edu The Switch Toolcall (which currently does nothing) can be written to save the userID of the currently active process. It can be called explicitly from within a process or by a timed interupt. The address of the program counter at the time of the call can be extracted from the stack (PER can be used for explicit calls and should be positioned in the parameter list where an interupt would normally push it relative to the stack pointer). I assume that interupts are disabled within Toolcalls and GSOS calls. From this address, you can use FindHandle to determine which memory block you are in and from the returned handle you can find the the userID (Handle + 4 I think). This assumes that the OS doesn't track running processes. Personally, by adding a process queue that keeps track of UserIDs as tasks are started would make the most sense. Patching NewHandle is the only required patch, if Switch is written properly. (this is because NewHandle is the common point for all memory allocations, regardless of source. FTA demos excepted. :) This is just off the top of my head, so there are details that will cause problems that I have not considered, but should give an enterprising programmer a start. BTW, The GS allows processes to spawn child processes. This has been built in since day One. This is a GREAT system, regardless of MHzage and age. I love it. UUCP: bkj386!pnet91!ericmcg INET: ericmcg@pnet91.cts.com