Path: utzoo!utgpu!watserv1!watmath!att!rutgers!mcnc!uvaarpa!murdoch!astsun7.astro.Virginia.EDU!cak3g From: cak3g@astsun7.astro.Virginia.EDU (Colin Klipsch) Newsgroups: comp.sys.mac.programmer Subject: CDEV/INIT Data Exchange, another way Keywords: cdev, INIT, system heap Message-ID: <1990Jun6.163604.12918@murdoch.acc.Virginia.EDU> Date: 6 Jun 90 16:36:04 GMT References: <55045@microsoft.UUCP> <1990Jun5.142604.11826@asterix.drev.dnd.ca> <8560@goofy.Apple.COM> Sender: news@murdoch.acc.Virginia.EDU Organization: University of Virginia Lines: 91 In article <8560@goofy.Apple.COM> lsr@Apple.COM (Larry Rosenstein) writes: >In article <1990Jun5.142604.11826@asterix.drev.dnd.ca> >louis@asterix.drev.dnd.ca (Louis Demers) writes: >> What happens if you disable the init and it is not loaded. Your >> resource is still there pointing to some area it has no right to > >I would place a magic series of bytes in memory and have the cdev check >that the resource points to the expected magic bytes. > >I've used this technique before, but users complained that the file in >their system folder was modified each time they booted, so it was always >being backed up. Here's my experience in writing TappyType, for what it's worth. . . The first technique I used was the one stated above: the INIT, on startup would store a pointer to my system heap variables in a resource of type "TapT", ID#2 (if I remember correctly). This has the advantage of being more "compatible" than just about any other solution I've heard of, but which has the above disadvantage. Plus, if the user is especially mischievious and does things like: locks the CDEV file, temporarily moves it to another folder, deletes the resource, etc., you've got problems. Using an entire auxilliary file for CDEV-INIT communication is subject to the same problems, and more. Of course, you can argue that anyone pretentious enough to commit any of these crimes against your CDEV deserves what he or she gets. The next method I used -- briefly -- was searching the system heap for a block of the right size, and which began with a particular magic string. After rereading the Memory Manager chapter and various tech notes, however, I soon realized that this is a BAD idea. It relies completely on the format of memory blocks, which very very very probably will change in the future at arbitrary times. I suppose you could search the system heap for a magic string without paying attention to block boundaries, but this still seems rather iffy. The current solution is a bit of a hack, but requires no auxilliary resources, nor installing a driver: The INIT installs the code and variables in system heap memory from a resource (remember to use DetachResource!), and patches a few traps. Among them is _AddResource. For CDEV-INIT communication, I needed a trap which could be called in some way that my patch could uniquely identify as being a call from the CDEV. My patch looks at every AddResource call. If the call is made with a resource of my particular type, my particular ID, if the name pointer points to four bytes of zeros, and if the return address is near a particular magic string, then my patch assumes the call was made by my CDEV. It then puts a pointer to my system heap variables in the four bytes of zeros pointed to by the name pointer, which my CDEV can pick up and use. The patch ends by jumping to the original AddResource address that the INIT found on startup (with NGetTrapAddress). Note that adding a resource which already exists is harmless, so the resource I "add" from the CDEV is just my options resource, which my CDEV has previously loaded anyway. If TappyType has not been installed, then my patch won't be there, and the the four bytes of zeros will remain just that after the call. Otherwise, if it's non-zero, it's a pointer to my system heap variables. To be even more anal-retentive, one could do the following: - check that the handle being added is a resource, and that it's the right size - check to see that the current resource file is of type "cdev" and creator "TapT" (using GetFileInfo) - pass a pointer to four zero bytes as before, but after the four bytes is also a pointer to the magic string; check for it In fact, I like that last one much better, now that I thought of it. I think I'll rewrite it that way for the next version. . . Hope this helps. AddResource is undoubtedly not the only trap you could use; it's just the first feasible one I thought of. The time overhead is low, particularly if you write it in assembly (as one should probably). I invite (constructive) criticism on this method. Anyone from Apple see anything wrong with this? (Anyone from anywhere, for that matter?) ---------------------------------------------------------------------- "May the forces of evil become confused on the way to your house." -- George Carlin Bemusedly, | DISCLAIMER: Colin Klipsch | This text is actually a horrendously UVa Astronomy Department | garbled excerpt from _Mating_Rituals_ Charlottesville, Virginia | of_West_African_Ostriches_, Vol IV, cak3g@virginia.edu | by Davis & Griffin, 1913, p. 137 ____________________________/ \_______________________________________