djb@wjh12.harvard.edu (David J. Birnbaum) (05/09/90)
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]
============================================================mlord@bnr-rsc.UUCP (Mark Lord) (05/09/90)
In article <489@wjh12.harvard.edu> djb@wjh12.UUCP (David J. Birnbaum) writes: >I recently added a routine to a tsr to release the environment >...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? I usually set my environment ptr to point at a small allocated "dummy" environment, containing nothing but the program name. This works with all memory mappers I have seen thus far. The dummy env has to allocated separately from the tsr if the tsr is ever to be unloaded, to avoid attempts to deallocate the same space twice. -Mark -- ______Mark S. Lord______________________ ______________________________ | ..uunet!bnrgate!carrsc!mlord | These are only MY opinions. | | or: bnr-rsc!mlord@bnrgate | I charge for official views. | |________________________________________|______________________________|
reh@icd.ab.com (Robert E. Hodge) (05/10/90)
>I recently added a routine to a tsr to release the environment >memory block before terminating. It was my understanding that DOS won't allocate that memory to later tasks, anyway, so why bother? Have you demonstrated conclusively some real use for that block? (Other than special use you might put it to in custom apps.) ++++ Bob Hodge +++++++++++++++++++++++++++++++++++++++++++ + "The chains of human slavery are formed of red tape" - + + Kafka + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
djb@wjh12.harvard.edu (David J. Birnbaum) (05/10/90)
In article <1191@abvax.UUCP> reh@icd.ab.com (Robert E. Hodge) writes (in response to my inquiry about releasing the environment block while loading a tsr): >It was my understanding that DOS won't allocate that memory to >later tasks, anyway, so why bother? Have you demonstrated >conclusively some real use for that block? (Other than special >use you might put it to in custom apps.) I assumed, with no particular justification, that dos would allocate the first block of memory that was of adequate size when it needed to allocate memory. The block freed by the environment would likely be too small for any program, but might reasonably be used for the en- vironment of subsequently loaded programs. Additionally, when a pro- gram expands its initial memory it is guaranteed that the expanded amount will be contiguous, but if it simply requests an additional block, it may be separate. I have demonstrated none of this conclusively. Can anyone out there help? Thanks, David ================================================================== David J. Birnbaum djb@wjh12.harvard.edu [Internet] ...!wjh12!djb [uucp] djb@harvunxw.bitnet [Bitnet]
mlord@bnr-rsc.UUCP (Mark Lord) (05/10/90)
In article <1191@abvax.UUCP< reh@icd.ab.com (Robert E. Hodge) writes: <<I recently added a routine to a tsr to release the environment <<memory block before terminating. < <It was my understanding that DOS won't allocate that memory to <later tasks, anyway, so why bother? Have you demonstrated It has been my OBSERVATION that the memory actually can get reused. DOS (on my system) uses it for the environment block of the next command I run. -- ______Mark S. Lord______________________ ______________________________ | ..uunet!bnrgate!carrsc!mlord | These are only MY opinions. | | or: bnr-rsc!mlord@bnrgate | I charge for official views. | |________________________________________|______________________________|
dixon@sagittarius.crd.ge.com (walt dixon) (05/10/90)
In a previous article Bob Hodge writes: >>I recently added a routine to a tsr to release the environment >>memory block before terminating. >It was my understanding that DOS won't allocate that memory to >later tasks, anyway, so why bother? Have you demonstrated >conclusively some real use for that block? (Other than special >use you might put it to in custom apps.) DOS uses one of three algorithms: first fit, last fit, or best fit to satisfy memory allocation requests. The default is first fit. If a returned environment block is big enough to satisfy the request, DOS will use it. Applications tend not to use int 21h ah=48h for memory allocation. The most common case would be to recycle the returned block to hold another copy of the environment, but its available for any other purpose as well. Walt Dixon {internet: dixon@crd.ge.com } {us mail: ge-crd } { po box 8 } { schenectady, ny 12301 } {phone: 518-387-5798 } Walt Dixon dixon@crd.ge.com
richard@calvin.spp.cornell.edu (Richard Brittain) (05/10/90)
In article <1191@abvax.UUCP> reh@icd.ab.com (Robert E. Hodge) writes: >>I recently added a routine to a tsr to release the environment >>memory block before terminating. > >It was my understanding that DOS won't allocate that memory to >later tasks, anyway, so why bother? Have you demonstrated >conclusively some real use for that block? (Other than special >use you might put it to in custom apps.) At least with dos 4.01, the lowest available block large enough is allocated, and I have often noticed that environment blocks get allocated in "holes" caused one way or another. I've seen at least one "setenv" type program that broke when it's environment block didn't immediately precede it in memory, but that has never been guaranteed behaviour as far as I know. Richard Brittain, School of Elect. Eng., Upson Hall Cornell University, Ithaca, NY 14853 ARPA: richard@calvin.spp.cornell.edu UUCP: {uunet,uw-beaver,rochester,cmcl2}!cornell!calvin!richard