Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!brutus.cs.uiuc.edu!apple!Apple.COM!lsr
From: lsr@Apple.COM (Larry Rosenstein)
Newsgroups: comp.sys.mac.programmer
Subject: Re: How can a CDEV "talk" to its INIT?
Message-ID: <5740@internal.Apple.COM>
Date: 13 Dec 89 00:40:03 GMT
Sender: usenet@Apple.COM
Organization: Objects-R-Us,  Apple Computer, Inc.
Lines: 32
References:<8183@cs.yale.edu> <871@excelan.COM>

In article <871@excelan.COM> mahboud@kinetics.com (Mahboud 
Zabetian,Kinetics,4511,9457194,) writes:
> Now when you change the settings in the cdev, load in your init resource,
> and jump to 2(A0) where A0 is the begining of the code.

That still doesn't help the CDEV find the INIT variables.  When the INIT 
is loaded it will place its settings at a certain place, which the CDEV 
needs to discover.

One technique is to record the address of the variables in the CDEV/INIT 
file.  I've used a resource for this, which contains the address.  At boot 
time, the INIT sets the address and writes the resource; the CDEV can load 
the resource and find the variables.  (I've always made the address point 
to a magic string so that the CDEV can check that the INIT was in fact 
loaded.)  The problem with this approach is that the INIT/CDEV file 
changes each time you boot, and will be backed up very often.

Another approach is to make the settings changes take effect when you 
reboot.  In this case, both the INIT and CDEV read the same settings 
resource, and the file only changs when the settings change.

Other people have suggested that the INIT install a driver, which the CDEV 
can use to talk to the INIT.  This is probably the cleanest solution.  
(Under System 7.0, it would be possible to achieve the same result with an 
IPC message from one to the other.)


Larry Rosenstein, Apple Computer, Inc.
Object Specialist

Internet: lsr@Apple.com   UUCP: {nsc, sun}!apple!lsr
AppleLink: Rosenstein1