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