kishon-amir@CS.Yale.EDU (amir kishon) (12/12/89)
I would like to write a CDEV that can change the global variables of a patch to GetNextEvent (the patch was done by an INIT that I wrote). How can I have both the CDEV and the patch (INIT) point to the same global variables, so the CDEV can change those values? Or are there any other ways to do that? namely, to keep some static global parameters referenced both by a CDEV code resource and an INIT code resource? I am working with Think C 4.0. HELPPPPPPPPPPPPPPPPPPPPPPP Thanks, -amir =============================================================================== Amir Kishon ARPA: kishon@cs.yale.edu Yale University, Computer Science Dept. kishon@yale.arpa P.O.Box 2158 Yale Station BITNET: kishon@yalecs.bitnet New Haven, CT. 06520-2158 UUCP: ...!yale!kishon (203) 432-1227 ===============================================================================
amanda@mermaid.intercon.com (Amanda Walker) (12/12/89)
In article <8183@cs.yale.edu>, kishon-amir@CS.Yale.EDU (amir kishon) writes: > How can I have both the CDEV and the patch (INIT) point to the same > global variables, so the CDEV can change those values? Or are there > any other ways to do that? Well, your INIT could install a little driver that accepted control calls to change your variables. This seems like the simplest way to me. Drivers actually aren't any harder than INITs as long as they don't actually do I/O :-)... Amanda Walker InterCon Systems Corporation --
mahboud@kinetics.com (Mahboud Zabetian,Kinetics,4511,9457194,) (12/13/89)
From article <8183@cs.yale.edu>, by kishon-amir@CS.Yale.EDU (amir kishon): > > I would like to write a CDEV that can change the global variables of a > patch to GetNextEvent (the patch was done by an INIT that I wrote). > How can I have both the CDEV and the patch (INIT) point to the same > global variables, so the CDEV can change those values? Or are there > any other ways to do that? namely, to keep some static global > parameters referenced both by a CDEV code resource and an INIT code > resource? I am working with Think C 4.0. HELPPPPPPPPPPPPPPPPPPPPPPP > > Thanks, > > -amir Make the first instruction in your init be a JMP to the third instruction. Make the second instruction be a JMP to code that will set up your globals for you(these globals will probably be imbedded in your patch). Now when you change the settings in the cdev, load in your init resource, and jump to 2(A0) where A0 is the begining of the code. Or if you can wait until reboot before changing things around, then just store that info in a resource and read it on the next reboot. -mahboud Standard Disclaimer: Don't mind me, I'm just babbling. ------------------------------------------------------------------------------ Mahboud Zabetian (415) 975-4511 mahboud@kinetics.com Kinetics/Excelan/Novell 1340 Treat Blvd, Suite 500 ...!ucbvax!mtxinu!kinetics!mahboud Walnut Creek, CA 94596
lsr@Apple.COM (Larry Rosenstein) (12/13/89)
In article <871@excelan.COM> mahboud@kinetics.com (Mahboud Zabetian,Kinetics,4511,9457194,) writes: > Now when you change the settings in the cdev, load in your init resource, > and jump to 2(A0) where A0 is the begining of the code. That still doesn't help the CDEV find the INIT variables. When the INIT is loaded it will place its settings at a certain place, which the CDEV needs to discover. One technique is to record the address of the variables in the CDEV/INIT file. I've used a resource for this, which contains the address. At boot time, the INIT sets the address and writes the resource; the CDEV can load the resource and find the variables. (I've always made the address point to a magic string so that the CDEV can check that the INIT was in fact loaded.) The problem with this approach is that the INIT/CDEV file changes each time you boot, and will be backed up very often. Another approach is to make the settings changes take effect when you reboot. In this case, both the INIT and CDEV read the same settings resource, and the file only changs when the settings change. Other people have suggested that the INIT install a driver, which the CDEV can use to talk to the INIT. This is probably the cleanest solution. (Under System 7.0, it would be possible to achieve the same result with an IPC message from one to the other.) Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
jackiw@cs.swarthmore.edu (Nick Jackiw) (12/13/89)
amanda@mermaid.intercon.com (Amanda Walker) writes: > In article <8183@cs.yale.edu>, kishon-amir@CS.Yale.EDU (amir kishon) writes: > > How can I have both the CDEV and the patch (INIT) point to the same > > global variables, so the CDEV can change those values? Or are there > > any other ways to do that? > > Well, your INIT could install a little driver that accepted control calls > to change your variables. This seems like the simplest way to me. Drivers > actually aren't any harder than INITs as long as they don't actually do > I/O :-)... > > Amanda Walker > InterCon Systems Corporation > -- Another popular method is to have the INIT allocate these globals in a block in the system heap. The first component of this block should be some sort of identification code with an extremely high probability of being unique within the system heap. (A good bet is a string containing your CDEV's name, your name, and your mother's name, separated by abstruse control characters...) Then when your CDEV needs to find the appropriate variables, you step through each block in the heap (not at all difficult, cf. IM#II:20-25) and check if the block has your "signature string" at the beginning, assume its your global variables. Check them for reasonableness, appropriate size, and proceed with caution. PowerStation uses this technique, for instance. [Some people shudder at this notion, because you are "guessing" where your globals are. On the other hand, the limit of probability is certainty, and if your signature is more than a few bytes, the chance of some random bitpattern matching it rapidly reaches the 1-in-billions-and-billions. For ultimate saftey, you could walk through the rest of the system zone and confirm that no one else has a block starting with that signature. If they do, how your cdev chooses to wig out in a big way is up to you.] -- _ _|\____ Nick Jackiw | Visual Geometry Project | Math Department / /_/ O> \ ------------+-------------------------+ Swarthmore College | O> | 215-328-8225| jackiw@cs.swarthmore.edu| Swarthmore PA 19081 \_Guernica_/ ------------+-------------------------+ USA
tim@hoptoad.uucp (Tim Maroney) (12/14/89)
In article <8183@cs.yale.edu> kishon-amir@CS.Yale.EDU (amir kishon) writes: >I would like to write a CDEV that can change the global variables of a >patch to GetNextEvent (the patch was done by an INIT that I wrote). >How can I have both the CDEV and the patch (INIT) point to the same >global variables, so the CDEV can change those values? There are a number of ways, none of which are great. You could use a driver merely to communicate between the two, but this uses up a unit table slot. In your case, I'd recommend a sort of overloading of your trap patch. One of the simplest ways to do this would be: Stash some distinctive value in the event record. For instance, make the whole thing a Pascal string containing the name of your INIT. The patch checks this every time, and if the event record is actually a string with the correct contents, and the event mask excludes all events, then stick a pointer to the global storage into the event message of the null event you return. This way, even if by some thermodynamic miracle you wind up getting passed an event record containing this string, with an event mask of zero, you still return a valid null event. If your CDEV does one of these strange GetNextEvent calls, though, it will gain access to its globals. Messy, yes, but very low-risk and reasonably efficient. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Now hear a plain fact: Swedenborg has not written one new truth: Now hear another: he has written all the old falshoods. And now hear the reason. He conversed with Angels who are all religious, & conversed not with Devils who all hate religion..." - Blake, "The Marriage of Heaven and Hell"
tim@hoptoad.uucp (Tim Maroney) (12/14/89)
From article <8183@cs.yale.edu>, by kishon-amir@CS.Yale.EDU (amir kishon): >> I would like to write a CDEV that can change the global variables of a >> patch to GetNextEvent (the patch was done by an INIT that I wrote). >> How can I have both the CDEV and the patch (INIT) point to the same >> global variables, so the CDEV can change those values? In article <871@excelan.COM> mahboud@kinetics.com (Mahboud Zabetian, Kinetics,4511,9457194,) writes: >Make the first instruction in your init be a JMP to the third instruction. >Make the second instruction be a JMP to code that will set up your globals >for you(these globals will probably be imbedded in your patch). > >Now when you change the settings in the cdev, load in your init resource, >and jump to 2(A0) where A0 is the begining of the code. No, INIT resources don't stick around *as* *resources* past the closing of their file during the INIT 31 procedure. There's no way to find out where the resource is after the INIT process has finished. Presumably, it's loaded itself (or possibly a separate resource) into the system heap or above BufPtr, but exactly where is up for grabs. The same goes of globals. They will not be loaded in at some fixed address on the machine, but wherever there happened to be space at the time the INIT was run by INIT 31. You can't figure anything out from the trap address either, because your INIT was not necessarily the last thing to patch the trap. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com FROM THE FOOL FILE: "Yet another piece of evidence that it's a Communist society which is being presented as good, but which we probably would not want to live in." -- Ken Arromdee on rec.arts.startrek, on the Federation's Red Menace