Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!usc!apple!jerryg From: jerryg@Apple.COM (Jerry Godes) Newsgroups: comp.sys.mac.programmer Subject: Re: Communications Toolbox questions Message-ID: <5598@internal.Apple.COM> Date: 5 Dec 89 12:40:30 GMT References: <9125@hoptoad.uucp> <36869@apple.Apple.COM> <9188@hoptoad.uucp> Organization: Apple Computer Inc, Cupertino, CA Lines: 66 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. > 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 The reason for the difference is the way we handle loading stuff if we're running on a smaller machine. On a large machine - all of the managers get loaded at init time into the System Heap. On the small machine - the managers get loaded at run time - into the App heap. 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... This is probably the best place to put the response to your other posting as well: >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. >I think the advantages of not installing the Toolbox in the already >badly overloaded System resource file speak for themselves, though I >will be glad to enumerate them if necessary. 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. >While I'm here, there's one more question. Is there any way to call >FTExec at VBL time? ... I expect the answer "no"; >I hope you realize this is a serious limitation of the system. There >needs to be a way to do true background transfers. You guessed correctly... 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. Again - another thing we need to add to the "next rev" wish list. Again - hope this was helpful... If you still want to argue the System File /Non System File issue - maybe we should take this to mail - I have a feeling this will be an argument where neither side is going to change their minds very quickly... Jerry Godes CommToolbox Janitor Apple Computer, Inc.