Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!CompuServe.COM!72347.2767
From: 72347.2767@CompuServe.COM ("Robert D. Royar, Cratylus Soft")
Newsgroups: comp.sys.atari.st.tech
Subject: Memory deallocation after TSR
Message-ID: <"901216143015.72347.2767.EHA33-1"@CompuServe.COM>
Date: 16 Dec 90 14:30:16 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 48

One technique is to load no go (seems to work as documented after TOS 1.4).  I
use this technique to load RSXs into my CLI.  They stay in memory until I ask
them to leave.  Each RSX registers with a resident manager that keeps up with
the address of a clean-up routine to call before kicking the program loose. 
The clean-up routine should Mfree() any Malloc()ed memory the RSX requested. 
It should also keep track of Files the RSX openned on its own and and other
variables that must be reset.  One RSX I have is an installable/uninstallable
printer spooler.  Others add to the CLI built-in command set.

Once cleanup is called the resident manager Mfree()s the basepage and the
prog's environment space.  I've been using this technique very successfully for
a few years without problems--except you should be careful about uninstalling
RSXs out of order since Malloc and Mfree lose efficiency then.

BTW RSX==Resident System eXtension (an old CPM acronym).

Robert Royar

Cratylus Educational Software

One thing I forgot in rushing to respond to the thread about deallocating
TSRs was that the RSX scheme I described does not depend on Ptermres().  In
fact if the RSX were to call either of the Pterm()s or Ptermres(), disaster
would ensue.  TOS believes the RSX's parent is the owner of all resources the
RSXs control, and the RSXs run as subroutines of the parent, not as separate
processes.  I don't use "just go" to start an RSX, rather when the RSX loads,
the resident manager computes the starting-instruction address from the
basepage returned by the Pexec() load, no-go call.  That starting address is
an init routine that sets up the RSX internally and registers its "official"
entry and clean-up routines with the resident manager.  For spoolers the init
routine is just a dummy, but for CLI extensions, the entry routine dispatches
that RSX's working code.

As an added benefit to the RSX and to keep RSX size small, the resident
manager installs pointers to some re-entrant routines in an RSX jump table.
In the RSX a function can call strcmp(str1,str2) normally, but the internal
routine is
  _strcmp: jmp _strcmp
The jump is patched up by the resident manager so the call goes into a
routine in the CLI's shared library. This added stuff is not required to make
an RSX scheme work, and would break in an environment where routine's
addresses may change after load, but for most uses on an ST, the jump table
is a real win.  Just being able to write a program that calls all the
standard C string functions and the formatted print functions without their
having to be linked into the executable saves quite a bit in file space,
executable space, and load time.

Robert Royar