Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!samsung!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim From: tim@hoptoad.uucp (Tim Maroney) Newsgroups: comp.sys.mac.programmer Subject: Re: Communications Toolbox questions Message-ID: <9260@hoptoad.uucp> Date: 11 Dec 89 23:02:09 GMT References: <9125@hoptoad.uucp> <36869@apple.Apple.COM> <9188@hoptoad.uucp> <5598@internal.Apple.COM> Reply-To: tim@hoptoad.UUCP (Tim Maroney) Organization: Eclectic Software, San Francisco Lines: 95 In article <9188@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >>This ties into another question -- why so much run-time overhead? It >>seems that the system assumes two megabytes. At least, the >>documentation says there's not enough free memory to run HyperCard if >>you install it under on megabyte. In article <5598@internal.Apple.COM> jerryg@Apple.COM (Jerry Godes) writes: >Ok... I'm going to attempt to answer this one for you... I just did a >bit of research on my system. The statistics: > System > 1 meg Systems <= 1 meg >Code in System Heap 27K 2K >Additional Heap Size +32K +8K > >Note: these numbers don't include the amount of memory needed for the >tools themselves - this is just the managers. So, the warning is >probably a bit conservative... But, it's a warning that things may not >work - not that they won't work... Strange that your numbers are so different from the other numbers we've seen here. 2K is pretty different from 440 bytes. But in any case, I accept this as a ballpark figure. May I suggest the alarmist note about memory usage be cut from the documentation? It's misleading. >>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. >Yup - we thought of that one - I think it was even implemented in an >older version of the toolbox . I don't remember all of the reasons for >going back to the current method. One was probably to avoid creating >another type of code resource that gets called a boot time - another >different place to put viruses... There must have been more reasons - >but I don't recall them right now. Have you seen my latest message on the subject, suggesting that the INITs be put into the Comm. Toolbox folder? Keep them in the ordinary format, but put them in a sub-folder. It should be noted that Comm. Toolbox is not the only piece of software to have this "sub-INIT" problem. There were recently a couple of messages dealing with the problems of installing protocols at INIT time under MacTCP (or *any* INIT-based TCP/IP mechanism, like TOPS TCP/IP). It is beginning to look like there should be some generally advertised method of putting INITs in a sub-folder of the system folder. INIT 31 could be hacked to look for a new resource containing a string (which contains a sub-folder name) in INIT files in the System Folder. So for instance, if you wanted MacTCP to look in a "TCP/IP" folder in the System Folder, you'd just put this string resource in the MacTCP file. INIT 31 would then, after closing the MacTCP INIT file., descend into the named folder and execute any INITs there, then return to its sweep over the System Folder. It wouldn't be at all hard to add this to INIT 31, and all protocol and communications add-ons would benefit. >Well, the other thing to realize is that the CommToolbox is part of the >system software. You don't say - "Well I'm not going to use the *pick >your least favorite manager here* so I'm not going to install it" You >install the system - and you get the system. Unfortunately, the >CommToolbox is being released pre System 7.0, so we have to have our >separate installation procedure until then. Once 7.0 arrives - there >is no choice in the matter - the CommToolbox is installed the same way >everything else in the system is installed. This is rather strange. Are you under the illusion that everyone is going to use System 7.0? System 6.0.x users will continue to have a choice in the matter of the installation of Comm. Toolbox. >>Is there any way to call FTExec at VBL time? ... I expect the answer "no"; >You guessed correctly... >Again - another thing we need to add to the "next rev" wish list. I think you need to do more than that. It may not be possible to add this feature to the architecture you have now. That would be highly unfortunate, because it would be too late to make the necessary changes to a distributed manager. You need to have at least a detailed design for this important feature before you ship your product. >To make it clear - in case the documentation >isn't clear: There are 3 (count 'em 3) calls that CAN be made at >interrupt level - CMRead, CMWrite, CMStatus. All other calls depend on >the resources being in the correct places. Why can CMRead, CMWrite, and CMStatus be called at the interrupt level? They involve a relocatable data structure describing the connection. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "The men promise to provide unconditionally for their wives. The women in turn serve unconditionally to provide the other household services necessary for the men to fulfill their obligations to the women. The women are satisfied because they have the men working for THEM." -- Colin Jenkins, soc.women