CXT105@psuvm.psu.edu (Christopher Tate) (03/25/91)
Is there anything wrong with this scheme:
My INIT opens up a resource of a custom type and ID (chosen to minimize
possible conflicts) which contains the data which needs to be shared by
the INIT and the cdev. Since the INIT file is first in the resource
search chain, the INIT will always open the resource out of its own
file.
The resource is MoveHHi'd into the top of the system heap and locked
down, but *not* DetachResource'd. The INIT gets various information
from this resource when needed.
Now, the cdev calls GetResource() on that same resource type and ID.
Since the cdev is in the same file as the INIT, it gets a handle to
the resource image that's already stashed away in the system heap.
By altering the proper fields and calling WriteResource(), the cdev
can alter these persistent parameters both permanently and dynamically;
the INIT will encounter the new values in the memory image the next
time it looks.
This scheme maintains the distinction between code and data; nothing
needs to be stored directly into the cdev or INIT resource images
themselves. Anyone see anything wrong with this approach?
-------
Christopher Tate |
| "Idle lawyers tend to become politicians,
cxt105@psuvm.psu.edu | so there is a certain social value
{...}!psuvax1!psuvm.bitnet!cxt105 | in keeping them busy."
cxt105@psuvm.bitnet |peirce@outpost.UUCP (Michael Peirce) (03/25/91)
In article <91083.154101CXT105@psuvm.psu.edu>, CXT105@psuvm.psu.edu (Christopher Tate) writes: > > Is there anything wrong with this scheme: > > My INIT opens up a resource of a custom type and ID (chosen to minimize > possible conflicts) which contains the data which needs to be shared by > the INIT and the cdev. Since the INIT file is first in the resource > search chain, the INIT will always open the resource out of its own > file. > > The resource is MoveHHi'd into the top of the system heap and locked > down, but *not* DetachResource'd. The INIT gets various information > from this resource when needed. > > Now, the cdev calls GetResource() on that same resource type and ID. > Since the cdev is in the same file as the INIT, it gets a handle to > the resource image that's already stashed away in the system heap. > By altering the proper fields and calling WriteResource(), the cdev > can alter these persistent parameters both permanently and dynamically; > the INIT will encounter the new values in the memory image the next > time it looks. > > This scheme maintains the distinction between code and data; nothing > needs to be stored directly into the cdev or INIT resource images > themselves. Anyone see anything wrong with this approach? Well, when the INIT is done running, its resource fork will be closed. INITs don't run forever, they get a quick chance to run at startup time and if they expect to be around later must stash parts of themselves in the system somewhere. What's wrong with creating a block in the system heap and using Gestalt to register the pointer to it? Then the INIT's resident code (patch/TimeManager task/whatever) and the cdev can ask Gestalt for it. -- michael -- Michael Peirce -- outpost!peirce@claris.com -- Peirce Software -- Suite 301, 719 Hibiscus Place -- Macintosh Programming -- San Jose, California 95117 -- & Consulting -- (408) 244-6554, AppleLink: PEIRCE
russotto@eng.umd.edu (Matthew T. Russotto) (03/27/91)
In article <91083.154101CXT105@psuvm.psu.edu> CXT105@psuvm.psu.edu (Christopher Tate) writes: >Is there anything wrong with this scheme: > >My INIT opens up a resource of a custom type and ID (chosen to minimize >possible conflicts) which contains the data which needs to be shared by >the INIT and the cdev. Since the INIT file is first in the resource >search chain, the INIT will always open the resource out of its own >file. > >The resource is MoveHHi'd into the top of the system heap and locked >down, but *not* DetachResource'd. The INIT gets various information >from this resource when needed. > >Now, the cdev calls GetResource() on that same resource type and ID. >themselves. Anyone see anything wrong with this approach? Just one, fatal, flaw. What happens when INIT 31 CloseResFile's your INIT? -- Matthew T. Russotto russotto@eng.umd.edu russotto@wam.umd.edu .sig under construction, like the rest of this campus.
jjoshua@romulus.rutgers.edu (J. Joshua) (03/27/91)
In article <91083.154101CXT105@psuvm.psu.edu> CXT105@psuvm.psu.edu (Christopher Tate) writes: >Is there anything wrong with this scheme: > >My INIT opens up a resource of a custom type and ID (chosen to minimize >possible conflicts) which contains the data which needs to be shared by >the INIT and the cdev. Since the INIT file is first in the resource >search chain, the INIT will always open the resource out of its own >file. This is howw I do it... Put an 8 byte 'signature' in your init just before an area to store some values to be placed by the CDEV. When you load your init during boot time, make a note of the memory location of where is loaded - it doesn't get moved (of course detach the init resource). Store this location in a resource (make sure that the init and the cdev are in the same file so they sharee the same resource fork). When the cdev is called it can open the resource and get the address stored there. It can then check an offset of the address to find the init's signature. If this is found, you know where you can store stuff that you want the init to find. JOn. -- ________ | | This Messsage A Service By: | | Closed Captioned Jon Joshua | | For the Hearing Impaired jjoshua@remus.rutgers.edu `----. .-' |/ #include <whittyComment.h>