Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!shadooby!oxtrap.aa.ox.com!oxtrap!time From: time@oxtrap.oxtrap.UUCP (Tim Endres) Newsgroups: comp.sys.mac.programmer Subject: Re: Communications Toolbox questions Message-ID: Date: 5 Dec 89 22:28:29 GMT References: <9125@hoptoad.uucp> <36869@apple.Apple.COM> <9194@hoptoad.uucp> Sender: time@oxtrap.aa.ox.com (Tim Endres) Reply-To: time@oxtrap.UUCP Organization: Oxtrap - Ann Arbor, MI Lines: 26 In-Reply-To: tim@hoptoad.uucp's message of 5 Dec 89 07:41:27 GMT Tim Maroney writes: >OK, this has been preying on my mind for a few hours and I have what >seems to be a good answer. INITs that install Comm Toolbox resources >in the linked list should not be given type INIT or RDEV to be picked >up by the INIT 31 mechanism. Instead, they should be give a new type, >say 'Comm', that INIT 31 won't pick up. Then the toolbox file, which >*is* of type INIT or RDEV, contains its own INIT-31-type resource that >only picks up files of the new type. Running INITs is pretty easy; the >real INIT 31 resource is only 474 bytes of code. I must further support Tim's idea for the CTB INIT's. If my user has a one megabyte system, then pulling the CTB INIT out of the SystemFolder and rebooting to get the memory back is not a big inhibitor. BUT, running the Installer to do this is unacceptable. I think making the CTB go into the System the way it does now is a poor choice. Also, is it really necessary to even make the 'Comm' inits? Couldn't INIT 31 be made smart enough to look for CTB first? Or, couldn't the INIT 31 be programmed to look for a resource in an INIT called 'Comm' which indicates that this INIT uses the CTB, and therefore must be delayed until CTB is loaded (or possibly not loaded in case of no CTB). ANYTHING, but what is done now would be better. tim