Path: utzoo!utgpu!attcan!uunet!husc6!bloom-beacon!mit-eddie!uw-beaver!microsoft!t-benw
From: t-benw@microsoft.UUCP (Benjamin Waldmin)
Newsgroups: comp.sys.mac.programmer
Subject: Re: sharing data between cdevs and INITs
Summary: Use device drivers (but LSC 3.0 is a REAL pain here)
Keywords: INIT cdev LSC DRVR
Message-ID: <1745@microsoft.UUCP>
Date: 20 Aug 88 02:09:51 GMT
References: <1739@microsoft.UUCP> <15808@apple.Apple.COM>
Reply-To: t-benw@microsoft.uucp (Benjamin Waldman)
Organization: Microsoft Corporation, Redmond, WA
Lines: 81

In article <15808@apple.Apple.COM> lsr@apple.com.UUCP (Larry Rosenstein) writes:
>In article <1739@microsoft.UUCP> t-benw@microsoft.uucp (I) wrote:
>>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 problem with this is that the INIT has to write to disk at startup
time, which I'd rather not do.

Actually, I've found a rather neat solution -- the device manager!!

I create a device driver.  In response to the open call, it patches the trap
I want to patch (and I open the driver at startup, in an INIT).  In response
to a status call, I return the address of my variables that I want the
cdev to access.  The only trick part is for the cdev to figure out the refnum
of the driver.  But Apple has already solved that problem - they tell you
how to do this in Tech note #71.

Unfortunately, there's one problem - Think C 3.0!!!
My driver has to be in the system heap, so it can stay alive all the time.
But while THINK C lets you set the resource flags for a code resource, it
doesn't let you do this for a driver.  So every time, after building the
driver, I have to start ResEdit, and set the system heap bit.

But, wait, it gets worse.  Think C lets you have global data in your
drivers by allocating a block in the heap for you, locking it, pointing
A4 to it, and referencing your globals off of A4.  But my data has to
be in the system heap!!!  So, in my open routine, I have to allocate
another block, in the system heap this time, copy my globals from where
Think C put them, and point A4 to my globals.  (Actually, I store the
handle somewhere in my code, and when my trap patch is called, I get
the handle from this location, lock it, dereference it, and set A4 to
the dereference).

There's still one problem, however.  Think C locks the handle that IT
allocated every time my driver is called.  Suppose I call my driver
later on, after the application heap has been reinitialized (which is
OK, since my driver is in the system heap). The handle that THINK C
allocated is no longer valid.  I wonder if THINK C's driver
glue will check the return value of its call to HLock, and what it will
do after this.  If it just calls me blindly anyway, it's fine, since
I'll just unlock Think C's handle and return.  Otherwise, I don't
know what will happen.  Things are complicated further by the fact that
that old handle may still point to a valid block (someone else's),
or may not point to anything at all.

#include 
Yes, I really do like LSC, but I really think that this is a severe
flaw.  I suppose what I really should do is hack through Think C's
driver glue, find their newhandle call, and change some bits so that
it allocates a block in the system heap for the global data rather than
the application heap. 

Rich, could you be of any help here?  Is there some magic word I
could change in THINK C so that the newhandle call is done to allocate
a block in the system heap?

Also, will version 3.1 let us keep drivers in the system heap?


Thanks,

Ben Waldman
Software Design Engineer,
Microsoft Corp.

Disclaimer:  These are my own thoughts, opinions, and ideas, and in no
way represent the views of my employer.