Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!zaphod.mps.ohio-state.edu!rpi!dali.cs.montana.edu!milton!uw-beaver!zephyr.ens.tek.com!tektronix!reed!orpheus
From: orpheus@reed.UUCP (P. Hawthorne)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Memory
Message-ID: <15996@reed.UUCP>
Date: 1 Feb 91 07:37:20 GMT
References: <1991Jan25.233122.2825@fennel.cc.uwa.oz.au> <48579@apple.Apple.COM> <15967@reed.UUCP> <5534@husc6.harvard.edu>
Reply-To: orpheus@reed.UUCP (P. Hawthorne)
Organization: Reed College, Portland OR
Lines: 42

>>     Even though it may be possible to pin down every time memory may get
>> moved around, it takes a significant amount of thought and time to do so.

>      In fact, it takes comparitively little of either, since all of the
>  traps that move memory are documented, and new ones are document as soon
>  as is practical. As for old ones suddenly starting to move memory, I doubt
>  that any action by Apple will cause this problem, since they rarely
>  break something so fundamental.

       Perhaps I should have said that it takes more time and thought than I
   want to divert from solving the problem at hand.

       Regarding memory movement, I assume I was mistaken. Sorry. I had been
   told that some traps which had not moved memory before, had begun to
   move memory in a recent release. It might have been in regard to an INIT
   that patched a trap.


>>     My largest problem with memory, now, is in overcoming the 32K limit on
>> variables in Think Pascal. Right about now, I would kill or die to see the
>> same attention that is being devoted to locking handles being devoted to
>> dynamic length objects and arrays.

>      Which 32K limitation? Variable size, local allocation, or global
>  allocation?

       Since you ask, my annoyance is at variable size. It is not that I
   mind working with memory, or pushing the boundaries of my pointers and
   handles out. It is more that I wish I could simply define an array and
   leave it at that. The limitation is reasonable in context, but I would
   not mind it being removed, if it were possible.

       The problem I had been having with dynamic length variables was 
   quite simple. Embarrassing, to tell the truth. I was using integers
   rather than longints, and was getting overflow errors. I should have
   remembered the warnings in the offscreen world and palette documentation
   about the same problem sooner.
       A simple correction and it works fine.
       Thanks for your response... It's nice to have Symantec represented.


       orpheus@reed