home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / mac / programm / 20459 < prev    next >
Encoding:
Text File  |  1992-12-30  |  2.3 KB  |  44 lines

  1. Newsgroups: comp.sys.mac.programmer
  2. Path: sparky!uunet!spool.mu.edu!umn.edu!csus.edu!netcom.com!gurgle
  3. From: gurgle@netcom.com (Pete Gontier)
  4. Subject: Re: HELP! INIT and patching probs
  5. Message-ID: <1992Dec31.002355.26458@netcom.com>
  6. Organization: cellular
  7. References: <C03AHq.9LF@news.cso.uiuc.edu>
  8. Date: Thu, 31 Dec 1992 00:23:55 GMT
  9. Lines: 33
  10.  
  11. cole@alexia.lis.uiuc.edu (Sandra Stewart-Cole) writes:
  12. >        The central problem is that I've got an INIT that installs some trap 
  13. >patches for various tasks (primarily a patch to PrGlue and one to SystemTask so
  14. >I can get regular frequent cpu time without VBL hassles) and I need these 
  15. >patches to have access to some resources (alerts and dialogs being the chief 
  16. >need) but I found no supported way to either find my own filename as an INIT, 
  17. >or to lock open the INIT's file so that I have a resource map to let resource 
  18. >calls work with.
  19.  
  20. I don't have the first clue where the -34 error is coming from, but you
  21. don't need to find out. And you don't need to go to low memory, either.
  22. A call to CurResFile and then PBGetFCBInfo will do nicely. If the resource
  23. file is opened more than once, the resource file reference number may
  24. not match to the file manager file reference number, which is what you
  25. need for the call to PBGetFCBInfo, but it seems that they match if the
  26. resource file is open only once, which is the case at INIT time.
  27. PBGetFCBInfo also works no matter where your INIT is installed in the
  28. special folder hierarchy in the System Folder. It doesn't work if the
  29. user moves your INIT after booting, but you can do a hierarchical search
  30. within the file system for a file with your creator code if you're
  31. worried about that.
  32.  
  33. Regarding leaving your file open: the INIT 31 mechanism (the INIT loader)
  34. does some pretty weird things to ensure that all resource files opened
  35. by an INIT get closed. I even went so far as to patch CloseResFile
  36. once to see if I could keep my own resource file open. No dice. INIT
  37. 31 goes to low memory and checks some resource map chain variables to
  38. see when they are restored to a state before it started the INIT. If
  39. you patch CloseResFile to not close your fork, INIT 31 vainly keeps
  40. trying. I considered munging the map chain, but it was too ugly a
  41. thought and I decided to open the file whenever I needed it.
  42. -- 
  43.  Pete Gontier // EC Technology // gurgle@netcom.netcom.com
  44.