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. #includeYes, 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.