xxiaoye@eleazar.dartmouth.edu (Xiaoxia Ye) (08/22/89)
Would someone explain the following weirdness?
the WIND resource' first 8 bytes are its positions on the screen: top,
left, bottom and right. I tried to save the window postions and so to
write to the first 8 bytes of the WIND resource.
I have my rectange declared as (it's in THINK C):
Rect myRect;
and I get a handle to the WIND resource:
myHandle=GetResource('WIND',MY_WIND_RES_ID);
after I lock the Handle and do the following to assignment to the
resource:
**myHandle=myRect.top;
**myHandle+=2;
**myHandle=myRect.left
... blah blah and did this for all four coordinates.
and do a ChangedResource, and UpdateResFile, etc ...
What happened was:
say that I have the following eight bytes in my WIND resource (in Hex):
0044 0043 0056 0098
and say that myRect.top = 0x60, myRect.left=0x60, myRect.bottom=0x80 and
myRect.right=0x80.
and when I examined what was written to the resource, I found out that
first 8 bytes of WIND resource became:
6044 6043 8056 8098
in another words, if I just do an integer assignment, I don't get 00
padding and have the proper alignment. Why??
And if I write a 0x132 to '0044', those two bytes will become '1324'
instead of '0132'. Why ??
Well, eventually, I gave up and wrote a little routine to copy the bytes
myself (actually the THINK C inline assembly would do the job).
Much thanks.
________________________________________________________________________
Xiaoxia Ye INTERNET/BITNET/UUCP: xxiaoye@eleazar.dartmouth.edu
Dartmouth College For more info: finger xxiaoye@eleazar.dartmouth.edutim@hoptoad.uucp (Tim Maroney) (08/22/89)
In article <15141@dartvax.Dartmouth.EDU> xxiaoye@eleazar.dartmouth.edu (Xiaoxia Ye) writes: >the WIND resource' first 8 bytes are its positions on the screen: top, >left, bottom and right. I tried to save the window postions and so to >write to the first 8 bytes of the WIND resource. A perfectly legitimate tactic -- this is how the system desk accessories save their changed positions and sizes. Doesn't work too well if you have multiple windows originating from the same window template, though, and that's probably the more common case. >I have my rectange declared as (it's in THINK C): >Rect myRect; >and I get a handle to the WIND resource: >myHandle=GetResource('WIND',MY_WIND_RES_ID); > >after I lock the Handle and do the following to assignment to the >resource: >**myHandle=myRect.top; **myHandle is a character, not an integer. Problem 1. >**myHandle+=2; If I've got my precedences sorted right, this will add two to the first character stored in the handle. Rather pointless. Probably what you meant was *myHandle += 2. However, this is evil, because you are changing the master pointer for a handle. You need to use your own pointer to do this sort of thing; don't mess with the master pointer which the handle indicates. Problem 2. >**myHandle=myRect.left >... blah blah and did this for all four coordinates. >and do a ChangedResource, and UpdateResFile, etc ... > >What happened was: >say that I have the following eight bytes in my WIND resource (in Hex): >0044 0043 0056 0098 >and say that myRect.top = 0x60, myRect.left=0x60, myRect.bottom=0x80 and >myRect.right=0x80. > >and when I examined what was written to the resource, I found out that >first 8 bytes of WIND resource became: >6044 6043 8056 8098 >in another words, if I just do an integer assignment, I don't get 00 >padding and have the proper alignment. Why?? Hmm. Looks like your pointer incrementing is working after all. I don't know why -- perhaps the version above is not what you have in your code. But the point is moot, as Rev. Jackson would say. You are only assigning to character-width fields because a Handle is a char **. >Well, eventually, I gave up and wrote a little routine to copy the bytes >myself (actually the THINK C inline assembly would do the job). If I were doing this, what I'd do would be a lot simpler: BlockMove(&myRect, *myHandle, sizeof(Rect)); To do your approach right, you need to declare an integer pointer like short *iPtr = (short *)*myHandle; iPtr[0] = myRect.top; iPtr[1] = myRect.left; and so on. I think the BlockMove is better. Better still, you can always declare the handle to be a Rect ** and just use the C assignment operator: Rect **myHandle; myHandle = (Rect **) GetResource('WIND', MY_WIND_RES_ID); **myHandle = myRect; -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Don't talk to me about disclaimers! I invented disclaimers!" - The Censored Hacker
svc@well.UUCP (Leonard Rosenthol) (08/23/89)
In article <15141@dartvax.Dartmouth.EDU> xxiaoye@eleazar.dartmouth.edu (Xiaoxia Ye) writes: >Would someone explain the following weirdness? > >the WIND resource' first 8 bytes are its positions on the screen: top, >left, bottom and right. I tried to save the window postions and so to >write to the first 8 bytes of the WIND resource. > > [ details of reading and writing the new data ] > PLEASE DON'T DO THIS! This is how Apple's DA's (Control Panel, etc.) save of their window position and it is BAD NEWS and Apple is setting another bad example for its developers!!! To begin with it will flag some/all of the virus detections utils, it also means that your application CAN NOT be used off of a locked volume (or protected server volume, etc.), it will also mod your appls mod date and when you ask your users for the date of the appls, they will not the correct date! I would suggest that your write the window position information either into a application level prefs file (either in the sytem folder or the same directory as the appls) or you have doc specific window prefs which get written into the document file (either data or res fork). -- +--------------------------------------------------+ Leonard Rosenthol | GEnie : MACgician Lazerware, inc. | MacNet: MACgician UUCP: svc@well.UUCP | ALink : D0025
palmer@tybalt.caltech.edu (David Palmer) (08/23/89)
In article <15141@dartvax.Dartmouth.EDU> xxiaoye@eleazar.dartmouth.edu (Xiaoxia Ye) writes: >Would someone explain the following weirdness? > >the WIND resource' first 8 bytes are its positions on the screen: top, >left, bottom and right. I tried to save the window postions and so to >write to the first 8 bytes of the WIND resource. > >I have my rectange declared as (it's in THINK C): >Rect myRect; >and I get a handle to the WIND resource: >myHandle=GetResource('WIND',MY_WIND_RES_ID); > >after I lock the Handle and do the following to assignment to the >resource: >**myHandle=myRect.top; >**myHandle+=2; Do you mean '*myHandle += 2;'? (I assume you are typing this from memory, otherwise you are doing the equivalent of '**myhandle = myRect.top + 2;') >**myHandle=myRect.left >... blah blah and did this for all four coordinates. >and do a ChangedResource, and UpdateResFile, etc ... DON'T DO THAT!!! You should NEVER change the value of a master pointer (singly indirected handle) The safe way to do this is: char *mypointer; myHandle = getResou... HLock(myHandle); myPointer = *myHandle; *myPointer = myRect.top; myPointer += 2; *myPointer = myRect.left; ...blah blah blah This is 'safe', and equivalent to your code, but it is wrong. > >What happened was: >say that I have the following eight bytes in my WIND resource (in Hex): >0044 0043 0056 0098 >and say that myRect.top = 0x60, myRect.left=0x60, myRect.bottom=0x80 and >myRect.right=0x80. > >and when I examined what was written to the resource, I found out that >first 8 bytes of WIND resource became: >6044 6043 8056 8098 > >in another words, if I just do an integer assignment, I don't get 00 >padding and have the proper alignment. Why?? A handle is just a doubly indirect pointer to a char. '**myHandle = myRect.top' means take the integer myRect.top, and put it in the character pointed to by the master pointer pointed to by myHandle. However, when you put something in a character, you are storing it in a single byte in memory. The second byte is a totally separate character. A correct way to do it would be to make the assignments with: *(int *)myPointer = myRect.top; a better way would be to change that 'int' to a 'short', so this will work on a compiler with 32-bit ints. A better way, clearer and probably faster, however is to just do: **(rect **)myHandle = myRect; You don't have to lock anything down, it is a single easy to understand instruction. This is still not good enough, however. The very best way, however, is to assign the actual eleemnt of the window structure you want, without having to rely on it being the first element of the structure. I don't have Inside Mac here, but the code should go something like: WindowHandle myWHandle; myHandle=(WindowHandle)GetResource('WIND',MY_WIND_RES_ID); /* ^ This cast takes ZERO CPU time to execute */ **myhandle.boundrect = myRect; /* ^ or whatever the element name is */ (followed by changedresource, etc.) David Palmer palmer@tybalt.caltech.edu ...rutgers!cit-vax!tybalt.caltech.edu!palmer "Direct quotes don't have to be exact, or even accurate. Truth is as irrelevant to a newspaper as it is to a court of law" - Judge Alarcon, 9th circuit court of appeals (paraphrased)
tim@hoptoad.uucp (Tim Maroney) (08/23/89)
In article <13271@well.UUCP> svc@well.UUCP (Leonard Rosenthol) writes: > PLEASE DON'T DO THIS! This is how Apple's DA's (Control Panel, etc.) >save of their window position and it is BAD NEWS and Apple is setting another >bad example for its developers!!! > To begin with it will flag some/all of the virus detections utils, it >also means that your application CAN NOT be used off of a locked volume (or >protected server volume, etc.), it will also mod your appls mod date and when >you ask your users for the date of the appls, they will not the correct date! Only if he keeps the resource in the application file. As long as he puts it in the preferences file, there's no problem. Considering the way the two of us blast anyone who suggests changing the application resource file, this is what I assumed he was proposing. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Those who restrain desire, do so because theirs is weak enough to be restrained..." - Blake, "The Marriage of Heaven and Hell"
oster@dewey.soe.berkeley.edu (David Phillip Oster) (08/23/89)
In article <8362@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes: >In article <15141@dartvax.Dartmouth.EDU> xxiaoye@eleazar.dartmouth.edu >(Xiaoxia Ye) writes: >>Well, eventually, I gave up and wrote a little routine to copy the bytes >>myself (actually the THINK C inline assembly would do the job). >If I were doing this, what I'd do would be a lot simpler: >BlockMove(&myRect, *myHandle, sizeof(Rect)); Xiaoxia Ye descends to assembly language and Tim calls a system call to do the what should be written as clear, concise C: ** (Rect **) myHandle = myRect; One advantage over the call to BlockMove: BlockMove is an operating system trap, not a tool trap. That means that C gets at it through a glue routine. If that glue routine is in a not yet t loaded segment (unlikely but possible) then a heap shuffle may occur during the LoadSeg to bring it in. myHandle my point to garbage by the time BlockMove gets there. To say nothing of the fact that the C routine compiles to about 4 instructions (load up two address registers and do to MOVE.Ls) --- David Phillip Oster 7 line signature follows Keith Sproul, head of microcomputer support at Union Carbide, NJ, complained about the poorly digitized fellatio on an IBM porno program. "Mac is better on everything, and this is no execption." -- "Computer Porn at the Office" by Reese Erlich, _This_World_, S.F. Chronicle, p.8, Aug 13, 1989 Arpa: oster@dewey.soe.berkeley.edu Uucp: {uwvax,decvax}!ucbvax!oster%dewey.soe.berkeley.edu
d88-jwa@nada.kth.se (Reply via mail or intl. +46 8 258 268...) (08/24/89)
In article <11689@cit-vax.Caltech.Edu> palmer@tybalt.caltech.edu.UUCP (David Palmer) writes: >A better way, clearer and probably faster, however is to just do: > **(rect **)myHandle = myRect; > >You don't have to lock anything down, it is a single easy to understand Wrong. Incorrect. What happens if a interrupt happens between the set pointers and the block move instruction ? And this interrupt happens to shuffle memory ? LOCK THE HANDLES first ! ALWAYS ! > **myhandle.boundrect = myRect; > /* ^ or whatever the element name is */ Both Inside Mac and the TechNotes tell us no to change any fields in windows or GrafPorts directly. But since everybody's doing it, they won't DARE change anything :-) -- This is your fortune from h+@nada.kth.se: As you read the scroll, it vanishes...
levin@bbn.com (Joel B Levin) (08/24/89)
In article <1465@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes: |In article <11689@cit-vax.Caltech.Edu> palmer@tybalt.caltech.edu.UUCP (David Palmer) writes: |>A better way, clearer and probably faster, however is to just do: |> **(rect **)myHandle = myRect; |> |>You don't have to lock anything down, it is a single easy to understand | |Wrong. Incorrect. What happens if a interrupt happens between the set |pointers and the block move instruction ? And this interrupt happens |to shuffle memory ? LOCK THE HANDLES first ! ALWAYS ! 1. This was originally about windows, I thought. These don't use handles and aren't relocatable. (I know, this isn't stated this way.) 2. Interrupts are the things that aren't supposed to shuffle memory. If this is application code, shouldn't this construct be OK? |Both Inside Mac and the TechNotes tell us no to change any fields in |windows or GrafPorts directly. But since everybody's doing it, they |won't DARE change anything :-) /JBL = UUCP: levin@bbn.com (new) or {backbone}!bbn!levin (old) INTERNET: levin@bbn.com POTS: (617) 873-3463 "The night was"
dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) (08/24/89)
d88-jwa@nada.kth.se (Jon W{tte) writes: >Wrong. Incorrect. What happens if a interrupt happens between the set >pointers and the block move instruction ? And this interrupt happens >to shuffle memory ? LOCK THE HANDLES first ! ALWAYS ! As I understand it, interrupt routines can't do any memory allocation stuff during the service of the interrupt. I always felt that this was one of the funner aspects of the Mac's OS. Am I wrong??? -- \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\|///////////////////////////////////////// David M. O'Rourke____________________|_____________dorourke@polyslo.calpoly.edu | God doesn't know, he would have never designed it like that in the first | |_ place. ____________________________________________________________________|
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (08/24/89)
In article <1465@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes: >Wrong. Incorrect. What happens if a interrupt happens between the set >pointers and the block move instruction ? And this interrupt happens >to shuffle memory ? LOCK THE HANDLES first ! ALWAYS ! Umm, pardon me, but it's a piss-poorly-behaved routine executed at interrupt time that shuffles relocatable objects around. I mean, we've discussed all of the memory compaction surprises, and this should NOT be one of them. v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.
amanda@intercon.uu.net (Amanda Walker) (08/24/89)
In article <1465@draken.nada.kth.se>, d88-jwa@nada.kth.se (Reply via mail or intl. +46 8 258 268...) writes: > Wrong. Incorrect. What happens if a interrupt happens between the set > pointers and the block move instruction ? And this interrupt happens > to shuffle memory ? LOCK THE HANDLES first ! ALWAYS ! Well, since routines that execute at interrupt time are forbidden from calling the Memory Manager (and thus moving memory), this isn't a problem. -- Amanda Walker InterCon Systems Corporation amanda@intercon.uu.net | ...!uunet!intercon!amanda
chrisj@ut-emx.UUCP (Chris Johnson) (08/24/89)
In article <1465@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes: >In article <11689@cit-vax.Caltech.Edu> palmer@tybalt.caltech.edu.UUCP (David Palmer) writes: >>A better way, clearer and probably faster, however is to just do: >> **(rect **)myHandle = myRect; >> >>You don't have to lock anything down, it is a single easy to understand > >Wrong. Incorrect. What happens if a interrupt happens between the set >pointers and the block move instruction ? And this interrupt happens >to shuffle memory ? LOCK THE HANDLES first ! ALWAYS ! Actually you don't need to lock anything down here. Code running at the interrupt level is *forbidden* by Apple to use any calls that can move or purge memory. I expect that this case is just *one* of the reasons that they're forbidden. Of course, locking things down never hurts, and if you choose not to lock blocks before you access them you have to be *extremely* careful not to make any Toolbox or OS calls that might, directly or indirectly, move or purge memory, thus causing your pointer to become invalid. So, extreme caution should be used, but it actually *is* possible to access ulocked blocks safely. The Inside Macintosh X-Ref contains the most up-to-date list of routines that can move or purge memory that I know of. In general, I'd say that you should check *every* routine you use against that table -- there are some surprises there. NumToString(), believe it or not, may move or purge memory, for instance. Once again, use extreme caution. Cheers, ----Chris
tim@hoptoad.uucp (Tim Maroney) (08/24/89)
In article <30836@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >Xiaoxia Ye descends to assembly language and Tim calls a system call >to do the what should be written as clear, concise C: > > ** (Rect **) myHandle = myRect; David, I listed exactly this as one alternative in my final paragraph! -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "I am convinced that cross-posting is an evil Satanic plot." -- Eugene Miya on soc.net-people, misc.headlines, misc.kids, misc.misc, news.misc, and soc.misc
mnkonar@manyjars.SRC.Honeywell.COM (Murat N. Konar) (08/24/89)
In article <17542@ut-emx.UUCP> chrisj@emx.UUCP (Chris Johnson) writes: >The Inside Macintosh X-Ref contains the most up-to-date list of routines >that can move or purge memory that I know of. In general, I'd say that you Be very careful. I have found that the list is not complete. I found a routine NOT listed that CAN move memory. (FindWindow, I think.) ____________________________________________________________________ Have a day. :^| Murat N. Konar Honeywell Systems & Research Center, Camden, MN mnkonar@SRC.honeywell.com (internet) {umn-cs,ems,bthpyd}!srcsip!mnkonar(UUCP)
tim@hoptoad.uucp (Tim Maroney) (08/24/89)
In article <11689@cit-vax.Caltech.Edu> palmer@tybalt.caltech.edu.UUCP (David Palmer) writes: >A better way, clearer and probably faster, however is to just do: > **(rect **)myHandle = myRect; >You don't have to lock anything down, it is a single easy to understand In article <1465@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes: >Wrong. Incorrect. What happens if a interrupt happens between the set >pointers and the block move instruction ? And this interrupt happens >to shuffle memory ? LOCK THE HANDLES first ! ALWAYS ! Wrong. Incorrect. Interrupts are forbidden to shuffle memory. Lock handles only when you need to; you risk fragmenting the heap otherwise. >> **myhandle.boundrect = myRect; >> /* ^ or whatever the element name is */ > >Both Inside Mac and the TechNotes tell us no to change any fields in >windows or GrafPorts directly. But since everybody's doing it, they >won't DARE change anything :-) So? He's not changing anything in a window or graphics port, he's changing something in a window template resource. If the difference isn't clear to you, I recommend re-reading the Window Manager chapter of Inside Mac. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "The time is gone, the song is over. Thought I'd something more to say." - Roger Waters, Time
tim@hoptoad.uucp (Tim Maroney) (08/24/89)
In article <17542@ut-emx.UUCP> chrisj@emx.UUCP (Chris Johnson) writes: >The Inside Macintosh X-Ref contains the most up-to-date list of routines >that can move or purge memory that I know of. In general, I'd say that you >should check *every* routine you use against that table -- there are some >surprises there. NumToString(), believe it or not, may move or purge memory, >for instance. Once again, use extreme caution. Don't see why that should be surprising -- it's a package, after all, so the system may do a resource fetch to get the code, which is stored in a PACK resource. All package routines may move or purge memory. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com A good flame strengthens its points; it does not stand in lieu of them.
d88-jwa@nada.kth.se (Reply via mail or intl. +46 8 258 268...) (08/24/89)
In article <13727@polyslo.CalPoly.EDU> dorourke@polyslo.CalPoly.EDU (David M. O'Rourke) writes: >d88-jwa@nada.kth.se (Jon W{tte) writes: >>Wrong. Incorrect. What happens if a interrupt happens between the set >>pointers and the block move instruction ? And this interrupt happens >>to shuffle memory ? LOCK THE HANDLES first ! ALWAYS ! > > As I understand it, interrupt routines can't do any memory allocation >stuff during the service of the interrupt. I always felt that this was one >of the funner aspects of the Mac's OS. Am I wrong??? That's right, USER interrupt routines can't shuffle memory. But try tracing a _HLock or something like it in MacsBug. You'll see that all Handle handling is part of DoVBLTask (At least on my SEx and MacsBug 6.0, might be that the procedure names are wrong for thia ROM ?) What is a VBL task ? I think it's an interrupt (at least, used to be on the plusses :-) I think that interrupts in the OS shuffle data, but ours may not. Damned segregation ! ,-) Happy hacking -- This is your fortune from h+@nada.kth.se: Anarchy is better that no government at all.
d88-jwa@nada.kth.se (Reply via mail or intl. +46 8 258 268...) (08/24/89)
In article <8377@hoptoad.uucp tim@hoptoad.UUCP (Tim Maroney) writes: In article <11689@cit-vax.Caltech.Edu palmer@tybalt.caltech.edu.UUCP (David Palmer) writes: A better way, clearer and probably faster, however is to just do: **(rect **)myHandle = myRect; You don't have to lock anything down, it is a single easy to understand In article <1465@draken.nada.kth.se d88-jwa@nada.kth.se (Jon W{tte) writes: Wrong. Incorrect. What happens if a interrupt happens between the set pointers and the block move instruction ? And this interrupt happens to shuffle memory ? LOCK THE HANDLES first ! ALWAYS ! Many people have said things about this. For instance: Wrong. Incorrect. Interrupts are forbidden to shuffle memory. Lock handles only when you need to; you risk fragmenting the heap otherwise. I should have said: "And unlock them again when you don't dereference them," but I though that was a clear issue. What's NOT a clear issue is the following: May OS interrupts move or purge memory ? Apple may do as it damned well pleases in many other cases, so what about this ? After all, most of the handle manipulation is in DoVBLTask in ROM... **myhandle.boundrect = myRect; /* ^ or whatever the element name is */ Both Inside Mac and the TechNotes tell us no to change any fields in windows or GrafPorts directly. But since everybody's doing it, they won't DARE change anything :-) So? He's not changing anything in a window or graphics port, he's changing something in a window template resource. If the difference isn't clear to you, I recommend re-reading the Window Manager chapter of Inside Mac. I'm sorry, I saw only boundsRect, which I translated as a struct Window element in my mind. You're right and I'm wrong in this case. Happy hacking everyone :-) -- This is your fortune from h+@nada.kth.se: A bird in the hand is worth what it will bring.
tim@hoptoad.uucp (Tim Maroney) (08/25/89)
In article <1478@draken.nada.kth.se> d88-jwa@nada.kth.se (Jon W{tte) writes: >That's right, USER interrupt routines can't shuffle memory. But try tracing >a _HLock or something like it in MacsBug. You'll see that all Handle handling >is part of DoVBLTask (At least on my SEx and MacsBug 6.0, might be that the >procedure names are wrong for thia ROM ?) The procedure names are best guess approximations. When you see the PC in DoVBLTask, all that means is that the nearest symbol Macsbug knows of is DoVBLTask. If you spend much time stepping through code in the ROM, you'll find that the names are wrong as often as they're right. >I think that interrupts in the OS shuffle data, but ours may not. Damned >segregation ! ,-) No, no, no. Interrupt driven code does not allocate or shuffle memory. Period. -- Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com "Those who restrain desire, do so because theirs is weak enough to be restrained..." - Blake, "The Marriage of Heaven and Hell"
rick@Jessica.stanford.edu (Rick Wong) (08/25/89)
In article <28932@srcsip.UUCP> mnkonar@src.honeywell.com (Murat N. Konar) writes: >In article <17542@ut-emx.UUCP> chrisj@emx.UUCP (Chris Johnson) writes: >>The Inside Macintosh X-Ref contains the most up-to-date list of routines >>that can move or purge memory that I know of. In general, I'd say that you > >Be very careful. I have found that the list is not complete. I found a >routine NOT listed that CAN move memory. (FindWindow, I think.) > Considering how scattered about this information is (volume 3, volume 5, and the X-Ref), and how subject it is to change, it seems that such a list would be a good subject for a tech-note. Keith??? Of course, it's probably safest to assume the worst, that ANY trap or procedure call can scramble the heap. Rick Wong rick@jessica.stanford.edu
keith@Apple.COM (Keith Rollin) (08/26/89)
In article <4826@portia.Stanford.EDU> rick@Jessica.UUCP (Rick Wong) writes: >Considering how scattered about this information is (volume 3, volume 5, >and the X-Ref), and how subject it is to change, it seems that such a >list would be a good subject for a tech-note. Keith??? > >Of course, it's probably safest to assume the worst, that ANY trap or >procedure call can scramble the heap. How about this: "Mac DTS doth hearby decree that ALL traps, including but not limited to _SetRect and _Unimplemented, move memory!" No, huh? I'll think about doing the technote, but please keep in mind that spare decades are awfully scarce these days, and I think I'm going to need one... ------------------------------------------------------------------------------ Keith Rollin --- Apple Computer, Inc. --- Developer Technical Support INTERNET: keith@apple.com UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith "Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions