Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!ucsd!ucsdhub!esosun!seismo!uunet!munnari!castan From: castan@munnari.oz (Jason Castan) Newsgroups: comp.sys.mac.programmer Subject: Re: sharing data between cdevs and INITs Summary: fixing data handle problem / Use traps ! Keywords: INIT cdev LSC DRVR Message-ID: <2311@munnari.oz> Date: 22 Aug 88 07:08:14 GMT References: <1739@microsoft.UUCP> <15808@apple.Apple.COM> <1745@microsoft.UUCP> Organization: Comp Sci, Melbourne Uni, Australia Lines: 60 In article <1745@microsoft.UUCP>, t-benw@microsoft.UUCP (Benjamin Waldmin) writes: > 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. > > 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). > You are doing the same algorithm that moire uses except that i use a control call to modify moire's behaviour. To make Think C allocate your globals in the system heap, just set the system heap bit for your DATA -16000 resource ! Yes, i agree its a flaw that Think C doesnt allow easy handling of resources. I just got 3.0 today :-) and had to reconcile myself that i wont be able to use its debugger with moire ;-( because of its design. However under multifinder, its a trivial thing to write a program that modifies all the bits to load the DRVR and DATA rez's to the system heap. For a solution involving less code and more hack to inter-process communication, try patching an uncommonly used trap like DebugStr(). Set your INIT to patch DebugStr(). When you want to communicate with the INIT, save ToolScratch (or CurApName) and put a signature in the low mem global. DebugStr checks the low mem global, sees that it's actually a message for the INIT, and the stringPtr passed is actually the message. DebugStr merely returns after processing the message. if the signature is not valid, call the real trap. On return from DebugStr, restore the old value of the global. I just thought of this today actually while working on another problem. I like it a whole lot, and should be reliable if you choose a good signature (if ShowInit does it, so can i !). > Thanks, > > Ben Waldman > Software Design Engineer, > Microsoft Corp. > Hope this helps, John Lim ps : cant help but give another plug for Think C 3.0. Great work ! Cant wait for the bugs to sprout out of the screen so i can squash them...