[comp.sys.atari.st] Loading programs.

stevef@dasys1.UUCP (Steve A. Feinstein) (09/19/87)

A program I have been writing uses Pexec() to invoke other programs
while everything seems fine, and the system operates normally.  Whenever
I execute any program that stays resident, i.e. DISKBAR, or NITE, 
a memory hole is created when my program terminates.  Depending on what
has been loaded this can leave a substantial void.  Does anyone know
if there is anyway to, say load a program into the top of the TPA
and execute it up there.  So that when it exits, there won't be any holes?



-- 
Steve Feinstein                  {allegra,philabs,cmcl2}!phri\
                                {bellcore,cmcl2}!cucard!dasys1!stevef
New York, NY, USA                                {philabs}!tg/

apratt@atari.UUCP (Allan Pratt) (09/21/87)

in article <1322@dasys1.UUCP>, stevef@dasys1.UUCP (Steve A. Feinstein) says:
> Does anyone know
> if there is anyway to, say load a program into the top of the TPA
> and execute it up there.  So that when it exits, there won't be any holes?

There is one way to do this with Pexec, but it requires knowing how much
memory the program will need (lots of heuristics here).

long topPexec(cmd,args,env,size)
char *cmd, *args, *env;
unsigned long size;
{
	unsigned long blocksize;
	char *addr;
	long ret;

	blocksize = Malloc(-1L);	/* find out size of largest block */
	if (block < size) {
		return ENSMEM;		/* largest block not big enough! */
	}
	addr = Malloc(blocksize);	/* allocate that block */
	Mshrink(addr,blocksize-size);	/* shrink it by size TSR needs */
	ret = Pexec(0,cmd,args,env);	/* exec the TSR */
	Mfree(addr);			/* free the padding */
	return ret;			/* return the exit code */
}

This procedure takes a "size" argument which is the amount of memory
the program in question will need for its text, data, bss, basepage,
environment, and stack/heap.  This is not a computable number: you
have to figure it out empirically.  text+data+bss+env+10K or so should
work, but you will always leave a small hole at the top of memory,
because TSR's always Mshrink a little bit.

============================================
Opinions expressed above do not necessarily	-- Allan Pratt, Atari Corp.
reflect those of Atari Corp. or anyone else.	  ...ames!atari!apratt