joseph@cooper.cooper.EDU (Joe Giannuzzi) (06/01/90)
I am writing a cdev that contains an INIT. I would like to exchange data between the two, but so far my attempts have failed. Does anyone have any recommendations about the best way to do this? Also, I have one DITL item that is an ICON. What is the best way for me to change the icon that it displays? Thanks. Joseph -> joseph@cooper.cooper.edu OR cmcl2!cooper!joseph Disclaimer -> Reality is just a figment of your imagination.
t-alexc@microsoft.UUCP (Alex CHAFFEE) (06/05/90)
In article <2695@cooper.cooper.EDU> joseph@cooper.cooper.EDU (Joe Giannuzzi) writes: > > I am writing a cdev that contains an INIT. I would like to > exchange data between the two, but so far my attempts have > failed. Does anyone have any recommendations about the best > way to do this? Also, I have one DITL item that is an ICON. > What is the best way for me to change the icon that it > displays? Thanks. > > Joseph -> joseph@cooper.cooper.edu OR cmcl2!cooper!joseph My favorite way is to have the INIT write a resource of type 'ADDR' into the preferences file (which should be buried safe in the system folder). The contents of this resource is just a longword pointing to the location of the shared data -- it can be a handle, or a pointer, or the proper value of A4. This is done once at startup, which is fine because the INIT code and data should be locked in memory for the duration.. This sounds kludgey, but it's actually quite clean and compatible. The INIT is guaranteed a writable system folder, even if it's been launched from a server. The existence and validity of the resource provides a quick way for the cdev to tell if the INIT's been loaded. The preferences file is going to keep the same name, even if the user renames the actual cdev/INIT file, so it'll be easy to find. Plus you don't have to walk through the system heap map, or install a driver, or any of the 1001 nasty alternative methods I've heard of... As for your ICON, can't you just set the itemHandle to the new ICON resource (after GetResourceing it in from disk)? I thought that was how the Dialog Manager dealt with ICONs, but I'm not sure. - Alex Chaffee chaffee@reed.bitnet or t-alexc@microsoft.uucp
louis@asterix.drev.dnd.ca (Louis Demers) (06/05/90)
t-alexc@microsoft.UUCP (Alex CHAFFEE) writes: >My favorite way is to have the INIT write a resource of type 'ADDR' >into the preferences file (which should be buried safe in the system >folder). The contents of this resource is just a longword pointing >to the location of the shared data -- it can be a handle, or a >pointer, or the proper value of A4. This is done once at startup, >which is fine because the INIT code and data should be locked in >memory for the duration.. >This sounds kludgey, but it's actually quite clean and compatible. >The INIT is guaranteed a writable system folder, even if it's been >launched from a server. The existence and validity of the resource >provides a quick way for the cdev to tell if the INIT's been loaded. 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 claim. Upon shutdown, Do you remove this resource ? what happens if you crash ? One way of validating this resource would be to compare for how long the mac has been booted and the modification time of the preference file. Is that what you do ? An interested reader Louis -- | Louis Demers | DREV, Defence Research Establishment,Valcartier | | louis@asterix.drev.dnd.ca | POBox 8800, Courcelette,Quebec, CANADA, G0A 1R0 | | (131.132.48.2) | Office: (418) 844-4424 fax (418) 844-4511 | +---------------------------+-------------------------------------------------+
lsr@Apple.COM (Larry Rosenstein) (06/06/90)
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. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
murat@farcomp.UUCP (Murat Konar) (06/07/90)
In article <1990Jun5.142604.11826@asterix.drev.dnd.ca> louis@asterix.drev.dnd.ca (Louis Demers) writes: >t-alexc@microsoft.UUCP (Alex CHAFFEE) writes: > >>My favorite way is to have the INIT write a resource of type 'ADDR' >>into the preferences file (which should be buried safe in the system >>folder). The contents of this resource is just a longword pointing >>to the location of the shared data -- it can be a handle, or a >>pointer, or the proper value of A4. This is done once at startup, [...] > 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 > claim. Upon shutdown, Do you remove this resource ? what happens [...] I embed a 4 character string (OSType) into my patch code at a known offset from its address and check for it before writing there. Works really well. f o d d e r -- ____________________________________________________________________ Have a day. :^| Murat N. Konar murat@farcomp.UUCP -or- farcomp!murat@apple.com
stoms@castor.ncgia.ucsb.edu (David Stoms) (06/08/90)
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. This would work (2^32-1)/2^32 of the time. A better solution might be to reset the modified date back to what it was before the change. Then it wouldn't be backed up. Another problem is that the "magic" string of bytes might be there if the INIT wasn't loaded (same propability). Unfortunately, I see no solution to this problem. You can't just expect the prefs file data to be reset each time the computer starts up. Josh.