Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!caen!hellgate.utah.edu!csn!boulder!boulder!pratt
From: pratt@boulder.Colorado.EDU (Jonathan Pratt)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Large Programs and Memory Management Questions
Message-ID: <1991Apr25.040219.28082@colorado.edu>
Date: 25 Apr 91 04:02:19 GMT
References: <1991Apr24.122618.13791@bmers95.bnr.ca> <1991Apr24.170354.20749@ux1.cso.uiuc.edu>
Sender: news@colorado.edu (The Daily Planet)
Reply-To: pratt@boulder.Colorado.EDU (Jonathan Pratt)
Organization: University of Colorado, Boulder
Lines: 58
Nntp-Posting-Host: fred.colorado.edu

In article <1991Apr24.170354.20749@ux1.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes:
>
[Stuff about making sure it's safe to call another segment]

>  if (EnoughMemoryForCodeSegment(32)) CallSomeFunction(withSomeArg);
>  else RefusePolitely();
>
I thought I'd share my version of EnoughMemoryForCodeSegment.  I don't
find it too inconvenient to use, and it's definitely preferable to giving
the end user a system error.  My typical usage is

if (LoadCheck((short *) AFunction) {
	AFunction(...);
	UnloadSeg(AFunction);
}

All of my base code (libraries, utilities, etc.) is preloaded and locked,
so the LoadCheck bit is used principally for isolated functions, although
for safety I use it before dispatching to routines associated with menus,
windows, etc. (which are known only by ProcPtr variables).  No flames
please about the in-line assembly.  You have to have it to call LoadSeg
(a trap THINK C doesn't seem to recognize).  I've been assueming that
in any case where LoadCheck succeeds, the call to the function won't
scramble memory provided the function itself doesn't.  Can anyone
contradict this?

short LoadCheck(theproc)
register short *theproc;
{
/* This next line makes sure there is a LoadSeg call in the jump table      *
   so that it's safe to extract the segment number to user with GetResource.*/
	if (*theproc == 0x3f3c && *(theproc+2)== 0xa9f0)
		if (!GetResource('CODE',*(theproc+1)) ) {
			GiveTheError(-108);
			return false;
		}
		else
			asm {
				Move.W 2(theproc),-(A7)
				Bra.S @in
				Bra.S @cont
				NOP
			@in
				DC.W 0xa9f0		/* _LoadSeg */
			@cont
			}
	return true;
}

An obvious improvement is to use ResError() instead of -108 in
GiveTheError.  That way you would accurately tell the user if it
the failure was caused by a disk error rather than insufficient
memory.

/* Jonathan Pratt            Internet: pratt@boulder.colorado.edu  *
 * UCHSC, Box A034           uucp: ..!ncar!boulder!pratt           *
 * 4200 E. Ninth Ave.                                              * 
 * Denver, CO 80262          Phone: (303) 270-7801                 */