Path: utzoo!attcan!uunet!cs.utexas.edu!usc!apple!dlyons From: dlyons@Apple.COM (David A. Lyons) Newsgroups: comp.sys.apple2 Subject: Re: Argh! That blasted StartUpTools()! Message-ID: <42769@apple.Apple.COM> Date: 8 Jul 90 00:10:41 GMT References: <9005291535.AA26340@apple.com> <42396@apple.Apple.COM> <1417@madnix.UUCP> <42637@apple.Apple.COM> <1990Jul7.044559.4967@laguna.ccsf.caltech.edu> Organization: Apple Computer Inc, Cupertino, CA Lines: 185 In article <1990Jul7.044559.4967@laguna.ccsf.caltech.edu> toddpw@tybalt.caltech.edu (Todd P. Whitesel) writes: [I (Dave L) said: ] >>I believe this is an area where your input would be helpful. I am >>interested in making it easier to use tools from NDAs, but I don't have >>all the answers. >I came up with a simple solution to this problem because I am working on a set >of graphics tools and I want them to be able to run in the desktop environment >without any of these silly problems. Please elaborate on the context here--your tools *are* going to be used as User Toolsets, called through the $E10008/$E1000C dispatch vectors, right? (Stealing System Toolset numbers is obviously bad, so I'll assume for now you're not doing that.) If you want your user toolsets to be usable by NDAs as well as applications, I thinka large amount of caution is in order here, since all user toolset numbers are owned by the current *application*, and there is no guarantee that a DA will be able to call them. (For example, what if there was a "Switcher" environment some day? User Toolsets would have to be swapped in and out depending on what application had control, so they might or might not be there when a NDA got control.) It doesn't seem to me that that the tool dispatcher can currently provide a safe way for third-party toolsets to be shared by applications and DAs. On the other hand, the Message Center does (see MessageCenter in the Tool Locator chapter of TB Ref 2 and MessageByName in the Tool Locator chapter of TB Ref 3). You can define the procedure for using your routines something like this: (1) Check the Message Center for a named message giving you the 4-byte entry point of your routines. If the message was there, great--you can call it. (2) If the message wasn't there, use InitialLoad to get the routines off disk, and call the code so it can initialize itself and publish its entry point in the Message Center. (The routines can have startup and shutdown calls that count the number of users--when it gets shut down to 0 it can remove the MessageCenter message and return "Okay, you can call UserShutDown on this ID now). >[...] In my view, system software >integrity and robustness is more important than backwards compatibility, >especially now when the only serious developers left are dedicated enough to >happily revise their software in order to make everyone's life easier. > >I know that Apple has always been a stickler for backwards compaitibility, but >their are times when you have to make a choice between two worthy goals, and >the future of the machine is ALWAYS more important than its past. Your reasoning works both ways--a diminished "serious developer base" means it's especially important to stay compatible with products that are out there that are *not* going to be revised. I'm perfectly willing to invent New and Preferred Ways of Doing Things, as long as they don't make things *worse* for software that was written to work as was recommended at the time. I *don't* think we have to decide between one or the other of backwards compatibility and improving the system. I think it's practical to consider both at the same time. >[...] (The recent >extensions to ProDOS -- lowercase filenames and dual-forked files -- were >implemented in a manner which insults the original designers of ProDOS. ProDOS >directories allow you to specify the length of a directory entry and a version >number which would have allowed for an orderly addition of case and resource >fork information. I would love to hear why this was not done.) Life isn't that simple. Here are two practical reasons *not* to change the length of a ProDOS directory entry and have new features depend on it: 1. Directories created under "new" system software would have larger directory entries, while the old directories would have the old- sized entries. So you grab a floppy and you don't know whether you will be able to put a lower-case name on there or not, and you don't know whether you will be able to create an extended file or not. (I don't think it would be good to have the system automatically extend the entry length of *existing* directories.) In other words, which do you prefer? (1) What we have now, or (2) Users being confused by alerts like: Can't create resource fork ($7x). or Sorry, could not create an extended file on :FLOPPY. Please create a new folder or format a new disk, and save your file there instead. This, I think, would qualify as Icky and Really Weird. 2. A fair amount of popular software would stop working. (Try it yourself--make a ProDOS disk with a larger entry length and smaller entPerBlock.) >Multi-Client tool usage procedure: >Call tool Status. If it is inactive, you load it or restore it from a >purged state (If possible. Does the standard tool startup procedure do this >for you already?) (Ack! You're proposing major changes to tool set management without detailed knowledge of how things work presently. I don't know how you did it, but most of your ideas came out reasonable anyway.) YES, LoadOneTool (and LoadTools and StartUpTools) automatically take care of trying to Restart (a Loader function) a tool set that has been put into a dormant purgable state. UnloadOneTool (and ShutDownTools and TLShutDown) automatically take care of putting tool sets into dormant state by calling UserShutDown (another Loader function) with the right flags. >Start up the tool and hand it a derived UserID. Any blocks allocated by >the tool set for your program will carry this ID. You may start it up again >with a new ID if you wish (one ID per open document, perhaps); so may an NDA or >CDA. The Tool will keep track of every ID it has been started up with, but will >not accept a MasterID as a startup argument. If you use the ID for other data, >be careful (see shutdown, below). By "derived UserID" do you mean one with a nonzero auxiliary ID ($1002 = master ID, $1102,$1202,...,$1f02 = derived IDs)? If so, this doesn't seem practical--there are only 15 derived IDs per master ID, and an app could easily use more than 15 tool sets. >[...] >When you are finished using the tool, Shut it down with the ID you gave >it in the startup call. >[...] >Check the tool's status. If it is no longer active then you should >unload the tool or mark it purgeable or something. This is a probably a reasonable approach for *your* tool set, since you're inventing it and get to define how it's used. To address the general problem of several *existing* applications using the same tool set, the system would have to field UnloadOneTool calls and screen some of them out--applications are justified in calling UnloadOneTool on a tool set that they just shut down. >If the Tool Locator doesn't >already do this then I would like to mark the tool purgeable and leave >a Message telling where to find it if it hasn't been purged, but I don't know >of any way to get a Message Type (other than calling DTS). Tool set code in RAM gets marked purgable when UnloadOneTool or TLShutDown is called (these call UserShutDown in the Loader). The loader Restart function tells you where the code is when you want it back, so there is no need for the Message Center here. (By the way, if you *do* ever want to use the Message Center, there is no need to get assigned a message type. You can use MessageByName instead-- see GS Toolbox Reference Volume 3, Tool Locator chapter.) >Can anybody blow holes in this? All programs must follow the same algorithm >for it to work, [...] the only change I am suggesting to the >normal tool procedure is in the Tool itself -- the Tool does not actually shut >down until all its users have shut down. The principle is good, but the details get Weird when you need to stay compatible with existing rules. (For what it's worth, note that the system could, if it wanted to, check the memory manager ID of the caller, by doing a FindHandle on the return address. That means the parameters to xxxStartUp and xxxShutDown functions would *not* have to be changed to implement a count-the-startups scheme.) >Matt/Dave: what's the official word on Tool management? Can an application >explicitly dispose of a Tool or force it to be reloaded from disk even if it >is active or restartable? I sincerely hope not, because it endangers this >scheme and puts serious dampers on any hope for a multitasking yet robust GS. Applications can do a lot of things, but the amount of "force" behind those things is debatable. For example, applications can call UnloadOneTool when they're done using a tool, but that doesn't mean UnloadOneTool actually has to unload it! There are a lot of possibilities. >Todd Whitesel >toddpw @ tybalt.caltech.edu -- David A. Lyons, Apple Computer, Inc. | DAL Systems Apple II Developer Technical Support | 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.