🚀 go-pugleaf

I recently added a routine to a tsr to release the environment
memory block before terminating.  This routine, lifted from the
Waite Group's MS-DOS Developer's Guide, worked as advertised,
but with a couple of quirks:

1) Memory mapping utilities can not identify the name of the program
once the environment has been deallocated.  I suspect this is because
they get the name from the undocumented file name appended to the
environment; no environment = no file name.  Is there any way to
coerce a program without an environment into reporting its name
correctly to such utilities?

2) The environment block is allocated before (below) the program memory
block, which means that releasing the environment creates a hole in 
memory.  This is not completely useless, since the block in question
might still be useful for the environment of the next program loaded,
which could be the same size, but it is clearly more useful to keep all
free memory contiguous.  Is there a way to coerce a program into loading
itself at the lowest possible address but loading its environment at the
highest possible address?  This would enable me to free the environment
block without fragmentation.

  Move'em, a loadhi utility for 286s by Qualitas, uses this approach.
When you load a tsr into high dos memory with Move'em, it allocates
memory for the program from the bottom up and memory for the environment
from the top down.  Move'em includes a feature that enables the user to
release the environment block for any program it loads; its memory
strategy insures that there will be no fragmentation.  I would like to
build this feature into the tsr itself, but I have no idea how it is
done.  I'd be grateful for any suggestions.

Thanks,

David


============================================================
David J. Birnbaum         djb@wjh12.harvard.edu [Internet]
                          djb@harvunxw.bitnet   [Bitnet]
============================================================