dubuc@IRO.UMontreal.CA (Martin Dubuc) (08/15/90)
I recently modified the MultiXfer telecom app. All worked well until I tested it on a Mac Plus/SE. It seems to me that there is a memory problem. My program works on a II, IIcx and IIci, but as soon as I execute it on a Plus or SE it bombs in my initialization routine, more precisely after the initialization of the managers, as soon as I access memory (while accessing an array or a pointer). I tried to correct the problem by allocating more memory with: SetApplLimit((Ptr) ApplicZone() + 256000L); MaxApplZone(); but the application now bombs when it calls MaxApplZone. Can someone point out what are the usual cases of incompatibility between a II and a Plus/SE or explain what happens in this particular situation? Martin Dubuc Local S-242, Pavillon Principal dubuc@IRO.UMontreal.CA Universite de Montreal Tel.: (514) 343-6111, poste 3507 "Qui a dit que rien ne pouvait arreter le progres?" -- un bureaucrate
stevec@Apple.COM (Steve Christensen) (08/16/90)
In article <1990Aug15.154812.9145@IRO.UMontreal.CA> Martin Dubuc writes: >I recently modified the MultiXfer telecom app. All worked well until >I tested it on a Mac Plus/SE. It seems to me that there is a memory problem. >My program works on a II, IIcx and IIci, but as soon as I execute it on a Plus >or SE it bombs in my initialization routine, more precisely after the >initialization of the managers, as soon as I access memory (while >accessing an array or a pointer). > >I tried to correct the problem by allocating more memory with: > > SetApplLimit((Ptr) ApplicZone() + 256000L); > MaxApplZone(); > >but the application now bombs when it calls MaxApplZone. > >Can someone point out what are the usual cases of incompatibility between a >II and a Plus/SE or explain what happens in this particular situation? Well, the II, IIcx and IIci usually have more memory to play around with, while the Plus and SE usually have a meg. Most likely when you grow the heap by 256K, you're crashing into the stack and beyond. A somewhat safer way to grow the heap would be to do something like this: bytesToGrow = StackSpace() - 1000L; SetApplLimit((Ptr) ApplicZone() + bytesToGrow); MaxApplZone(); StackSpace() returns the number of bytes between the current stack pointer and the end of the application heap. Leaving some extra bytes for the stack to expand is a good idea, and you'll have to play around to determine what a good amount is... steve -- ____________________________________________________________________ Steve Christensen Internet: stevec@goofy.apple.com Apple Computer, Inc. AppleLink: STEVEC 20525 Mariani Ave, MS 81-CS CompuServe: 76174,1712 Cupertino, CA 95014 "You just contradicted me." "No I didn't." ____________________________________________________________________
daven@svc.portal.com (08/17/90)
In article <1990Aug15.154812.9145@IRO.UMontreal.CA> dubuc@IRO.UMontreal.CA (Martin Dubuc) writes: >I tried to correct the problem by allocating more memory with: > > SetApplLimit((Ptr) ApplicZone() + 256000L); > MaxApplZone(); > >but the application now bombs when it calls MaxApplZone. I believe that calling MaxApplZone() should be sufficient. Setting the size of the ApplLimit by a fixed positive amount could cause problems. What happens if the user set the multifinder partition size to a value less that 256k? MaxApplZone() is supposed to expand the heap to it's fullest possible extend. Cheers! Dave Newman -- ------------------------------------------------------------------------------- Dave Newman - Sofware Ventures | daven@svc.portal.com | AppleLink: D0025 Berkeley, CA (415) 644-3232 | AOL: MicroPhone | CIS: 76004,2161 -------------------------------------------------------------------------------