Path: utzoo!attcan!uunet!microsoft!benw
From: benw@microsoft.UUCP (Ben WALDMAN)
Newsgroups: comp.sys.mac.programmer
Subject: Re: CDEV/INIT Data Exchange, another way
Keywords: cdev, INIT, system heap
Message-ID: <55103@microsoft.UUCP>
Date: 8 Jun 90 21:35:34 GMT
References: <55045@microsoft.UUCP> <1990Jun5.142604.11826@asterix.drev.dnd.ca> <8560@goofy.Apple.COM> <1990Jun6.163604.12918@murdoch.acc.Virginia.EDU>
Reply-To: benw@microsoft.UUCP (Ben WALDMAN)
Organization: Microsoft Corp., Redmond WA
Lines: 29

On cdev-INIT communication:
	One problem that a lot of the proposed solutions have is that they
assume they can write to disk.  This won't be the case if the user boots
off a locked floppy.

	The way I do it is to write my what's really my INIT as a driver.
Then, the actual INIT resource opens the driver by name, putting into the
system heap. (And the driver's open routine patches the traps I want to
patch, etc.). The driver also provides a status call, which returns the
address of its globals.

	The cdev, when it wants to communicate with the INIT, can simply
look through the unit table (this is described in a tech note), and find
the driver (by name).  Then, the cdev can make a status call to the driver,
and, voila, the status call returns the info the driver needs.  In my case,
I returned a pointer to the INITs globals (the init is locked in memory),
but you could, of course, return a handle, or an address of a function you
wanted to call, etc.

	The scheme fails if a dorky user changes the name of the DRVR resource
with ResEdit, but will still succeed if the DRVR gets renumbered.

Ben Waldman
Software Design Engineer
Excel Development Team
Microsoft Corp.

Disclaimer:  These are my thoughts, idea, and opinions, and are in no way,
indicative of those of my employer.