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