Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!mit-eddie!uw-beaver!zephyr.ens.tek.com!tektronix!reed!chaffee
From: chaffee@reed.UUCP (Alex Chaffee)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Modifying Inits
Message-ID: <15669@reed.UUCP>
Date: 9 Nov 90 21:41:07 GMT
References: <2351.2737EA8E@blkcat.fidonet.org>
Organization: Reed College, Portland OR
Lines: 44

In <2351.2737EA8E@blkcat.fidonet.org> Ken.Knight@f421.n109.z1.fidonet.org (Ken Knight) writes:

>I am in the process of writing a CDEV/INIT combination. The CDEV will be 
>used to select various modules to run (like Pyro! or After Dark) and set 
>some general parameters. I'm not quite sure how to pass the information 
>to the INIT. My best guess now is that I should store the data in a 
>resource in the INIT/CDEV and then call something like OpenResFile() to 
>get the newests info and the code for the module to run (each module 
>would be stored in its own distinct code-type resource). Is this the 
>best way to go? Are there any articles on this or similar subjects 
>(modifying the way an INIT runs during the current session)?

This is one of those great undocumented problems with no clean solution.
It's basically unsafe to save the data in the init file itself, since users
have a habit of renaming inits and it'd be hard to find your data if you did
that.  So put it in a preferences file in the system folder (or, better yet,
in the preferences folder).  That way both the INIT and the cdev will know
exactly where to find it.

If you don't mind having to reboot each time the information changes, then
all you'd have to do is an OpenResFile on that file (with appropriate error
checking if it's not there).  If you want the changes to be instantly known
to both the INIT and the cdev, there are a number of options, ranging from
having the INIT install a driver which moderates communication to using
Gestalt's "unique ID" feature to (my favorite) having the INIT allocate a
pointer or handle for its data in the system heap at startup, then saving
its address in an 'ADDR' resource in the preferences file, where the cdev
can find it.  Naturally, the block would start with a sanity check, like
your file signature, to catch old 'ADDR' resources if the INIT fails...

Is that perfectly clear? :-)

Isn't there something in the UMPG about this?  If not, there should be...

 - Alex

>   	Ken Knight, Ken.Knight@f421.n109.z1.fidonet.org
>   	via The Black Cat's Shack's FidoNet<->Usenet Gateway
>	    blkcat.fidonet.org   and   Fidonet 1:109/401
-- 
Alex Chaffee
chaffee@reed.{UUCP,BITNET}
Reed College, Portland OR 97202
____________________