[comp.sys.mac.programmer] Globals in Device Drivers, LSC 3.0 ??

mkent@dewey.soe.berkeley.edu (Marty Kent) (02/24/89)

I'm building a device driver to implement journalling (as hinted at in
IM-I), using Think C 3.0.  Things seem to be okay except my globals aren't
working.  The Think manual (pg 76-77) says the driver glue is supposed to
pre-allocate space for the globals in the device control block's
dCtlStorage field, and that the device's Open routine should check to make
sure that's been done properly (i.e. the field should be a handle rather
than 0). When I read this I assumed the implicit possible problem was the
usual one with dynamic storage allocation, i.e. maybe there wasn't enough
space.  

It turns out my Open routine *is* finding a 0 in the dCtlStorage
field. Since I'm running with 8Meg of memory on a Mac II, I know there's
enough memory.  (In fact, when I added an explicit call to NewHandle in my
Open routine, it worked fine.)  Does anyone have any ideas as to what
I might be doing that's causing the driver glue to fail to allocate the
globals?

By the way, if I let the driver open with a null dCtlStorage, the
individual routines work fine, but they can't communicate with each
other. This is all running under MultiFinder, System 4.3, Finder 6.0. Any
clues will be much appreciated!


Marty Kent  	Sixth Sense Research and Development
		415/642 0288	415/548 9129
		MKent@dewey.soe.berkeley.edu
		{uwvax, decvax, inhp4}!ucbvax!mkent%dewey.soe.berkeley.edu
Kent's heuristic: Look for it first where you'd most like to find it.

siegel@endor.harvard.edu (Rich Siegel) (02/24/89)

In article <28152@ucbvax.BERKELEY.EDU> mkent@dewey.soe.berkeley.edu (Marty Kent) writes:
>
>It turns out my Open routine *is* finding a 0 in the dCtlStorage
>field. Since I'm running with 8Meg of memory on a Mac II, I know there's
>enough memory.  (In fact, when I added an explicit call to NewHandle in my
>Open routine, it worked fine.)  Does anyone have any ideas as to what
>I might be doing that's causing the driver glue to fail to allocate the
>globals?

	8 MB of installed RAM does not imply 8MB of space for your program,
particularly under MultiFinder. It's possible that there's not enough space
in the heap you're running in to allocate the handle. You may want to place
a debugger trap at the beginning of your main(), and watching where the
dCtlStorage is getting allocated, or place a TMON trap intercept on _NewHandle.

	Beyond that, I'm stumped....

		--Rich



Rich Siegel
Staff Software Developer
THINK Technologies Division, Symantec Corp.
Internet: siegel@endor.harvard.edu
UUCP: ..harvard!endor!siegel
Phone: (617) 275-4800 x305

siegel@endor.harvard.edu (Rich Siegel) (02/24/89)

In article <36372@bbn.COM> levin@BBN.COM (Joel B Levin) writes:
>In MPW, the driver glue does not allocate the global storage block;
>you have to do it in your open routine.  I feel fairly confident that
>the same is true for THINK C, since the glue has no way of knowing how
>big a block to request.

	In LightspeedC, the determination of the global space size is made,
and the glue will automatically allocate dCtlStorage for the necessary
amount.

		--Rich




Rich Siegel
Staff Software Developer
THINK Technologies Division, Symantec Corp.
Internet: siegel@endor.harvard.edu
UUCP: ..harvard!endor!siegel
Phone: (617) 275-4800 x305

levin@bbn.com (Joel B Levin) (02/24/89)

In article <1262@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes:
|In article <36372@bbn.COM> levin@BBN.COM (Joel B Levin) writes:
|>In MPW, the driver glue does not allocate the global storage block;
|>you have to do it in your open routine.  I feel fairly confident that
|>the same is true for THINK C . . .
|	In LightspeedC, the determination of the global space size is made,
|and the glue will automatically allocate dCtlStorage for the necessary
|amount.

I spoke with misplaced confidence, unfortunately; I know something
about the Mac and MPW, but not LSC.  My apologies for any confusion I
might have engendered.

	/JBL
=
UUCP:     {backbone}!bbn!levin		POTS: (617) 873-3463
INTERNET: levin@bbn.com