Path: utzoo!utgpu!attcan!uunet!husc6!bloom-beacon!apple!lsr From: lsr@Apple.COM (Larry Rosenstein) Newsgroups: comp.sys.mac.programmer Subject: Re: sharing data between cdevs and INITs Keywords: INIT cdev Message-ID: <15808@apple.Apple.COM> Date: 19 Aug 88 15:32:12 GMT References: <1739@microsoft.UUCP> Reply-To: lsr@apple.com.UUCP (Larry Rosenstein) Organization: Advanced Technology Group, Apple Computer Lines: 50 In article <1739@microsoft.UUCP> t-benw@microsoft.uucp (Benjamin Waldman) writes: >Does anyone out there have a suggestion for sharing data between a cdev >and a patch installed as an INIT? Here's what I have done in my cdevs that have INITs. First, I keep configuration information in a resource in the file. When the INIT installs itself, it copies this information into the system heap. The INIT saves the address of the data (eg, a handle) in some well-defined place. (Generally, I reserve a few bytes of storage in the same heap block containing the installed code.) I also had the INIT installer record in a special resource, where the INIT was installed. The cdev can then read this resource, locate the INIT, and read/set its configuration. I also have the INIT leave some 4-byte ID around in memory. The cdev checks this to ensure that the address it has is valid. (You could increase this to 8-bytes for extra insurance.) The cdev needs to at least change the configuration resource stored in the file. If it can locate the installed INIT in RAM, then it cal also change the configuration in RAM, which will cause changes to take effect immediately. If the cdev can't locate the INIT in RAM (because it hasn't been installed, or the special ID wasn't located), then changes will take effect when you reboot, andI added a little message to that effect in the cdev window. This does require that the INIT be able to write to the disk, which means the modification date on the file changes each time you boot. If the disk is write-protected, then the INIT won't be able to record its location in RAM. In some cases, the INIT would be installed in the same spot as last time, so the cdev will still be able to locate it. Otherwise, configuration changes won't take effect immediately. (If the disk is always write-protected, then there is no way to save any configuration changes.) I wouldn't try to scan through the system heap for the reasons you mentioned. An alternative is to make configuration changes take effect when you reboot. This is easy to implement, since the cdev doesn't have to do anything with the INIT, but it is inconvenient for the user. You could also use a shared configuration file. The cdev can easily modify that file, but the INIT would have to periodically check to see if it has changed. (You could watch for changes in modification dates.) Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr