home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Hall of Fame
/
HallofFameCDROM.cdr
/
util2
/
tsrcom.lzh
/
TSR.DOC
< prev
Wrap
Text File
|
1986-09-07
|
15KB
|
334 lines
****************************************************************
* Version 2.1 *
* The TSR package is a group of programs useful in managing *
* DOS memory, and in particular managing memory-resident *
* utilities. TSR stands for "Terminate and Stay Resident". *
* *
****************************************************************
A. MARK, FMARK and RELEASE
================================================================
MARK.COM and RELEASE.COM are used to remove memory-resident
programs from memory, without requiring a system reboot, and
without the usual problems of creating holes or leaving
interrupts dangling. The two programs are used simply as follows:
1) Run the program MARK.COM before installing any memory-
resident program that you may wish to deinstall later.
This marks the current position in memory and stores the
DOS interrupt vector table (all interrupts from 0 to FFH).
2) Install whatever TSRs that you want to use, in the normal
way that you install them.
3) When you want to deinstall all TSRs above the last MARK,
run the program RELEASE.COM. This will release all of the
memory above (and including) the last MARK, and restore
all interrupt vectors taken over by the memory resident
programs.
MARK and RELEASE can be "stacked" as many times as desired.
RELEASE releases the memory above the last MARK call. MARK uses
about 1600 bytes of memory each time it is called. This 1600
byte region is also released when a RELEASE is done. MARK memory
usage is dominated by the copies of the DOS interrupt vector
table (interrupts 0..FFH) and the copy of the EMS page map
(blocks 0..31 only) which MARK keeps when it goes resident.
================================================================
MARK and RELEASE can optionally be called with a single command
line parameter:
MARK MarkName
RELEASE MarkName
In this way a particular mark is given a name. Calling RELEASE
with the same name will release all memory above and including
the mark of that name, also releasing any intermediate marks in
the process. If no mark of the proper name is found, RELEASE
will halt with a warning. A RELEASE call with no MarkName
specified will release the last MARK, whether or not that MARK
was named.
The MarkName can be any text string up to 126 characters in
length. It may not contain embedded blanks or tabs. Case (upper
or lower) is not important when matching MarkNames.
MarkName supports an additional feature. If the MarkName begins
with ! (exclamation point), then the mark is called a "protected
mark". That mark can be released *only* by an exact match to its
name (including the exclamation point). A protected mark will
NOT be released with an "unnamed" RELEASE. Any named or unnamed
RELEASE will stop without releasing any blocks if it encounters
a protected mark that it does not match exactly.
================================================================
As of version 1.4, MARK and RELEASE also control Expanded memory
(Lotus/Intel/Microsoft EMS). They have been tested with READY!
and with the TurboPower Software expanded memory disk cache, as
well as with the device drivers used by the STB Expanded Memory
Card.
WARNING: if a resident application allocates expanded memory at
some time *after* going resident and after the last MARK made,
that expanded memory will be released by a call to RELEASE. The
current expanded memory manager (EMM) does not give us enough
information to avoid this possibility. Fortunately, there are no
known memory resident programs which perform this dynamic
allocation of expanded memory. We hope that the EMM will be
upgraded before such applications are designed.
================================================================
As of version 1.6, RELEASE takes special precautions to allow it
to release extra invocations of the DOS command processor. In
the simplest form, an extra command processor is obtained by
typing COMMAND at the DOS level. Many multitasking or switching
utilities also utilize this feature of DOS, and these utilities
can now be managed via MARK and RELEASE.
================================================================
Due to the way DOS handles batch files, there are certain
limitations on using RELEASE within batch. It is *not* possible
to perform the following sequence of events successfully:
First, from the command line:
MARK
SK {or any other resident program or programs}
Then, within a batch file:
RELEASE {get rid of SK and MARK}
LOTUS {run Lotus using the additional memory}
MARK {put SK back in place}
SK
DOS allocates a small memory block prior to running any batch
file. It does not allow that block to be deallocated from within
the batch file without various errors occurring. As a result, in
this case the MARK and SK memory blocks are effectively trapped
until the batch file is completed, after which the memory will
be reusable. Indeed, if you run the batch file presented above,
you will get MARK and SK installed above a big hole in memory
left by the previous images of MARK and SK.
As of version 1.9, RELEASE guards against this possibility. If
it senses that you are attempting to release memory trapped by a
"batch control block", it writes a warning message to that
effect. It still releases the memory, but when it exits it
passes back a return code of 1 rather than the usual value of 0.
It *is* possible to get the desired effect in either of at least
two ways. First, you could make two batch files and call them
one after the other:
Batch file #1:
RELEASE
Batch file #2:
LOTUS
MARK
SK
In this case, running RELEASE in batch file #1 has the same
effect as running RELEASE from the command line. However,
directly calling the second batch file from the first doesn't
always seem to work either. The only sure bet appears to be the
use of a keypoker like KEY-FAKE or PCED's KEYIN, modifying Batch
#1 as follows:
RELEASE
KEY-FAKE "batch2" 13
A better way to make these things happen is to use the public
domain program CED, or its commercial upgrade PCED. These
programs allow you to define "synonyms" for groups of commands.
The commands execute one after the other just like a batch file.
However, the synonyms do not create an extra batch control
memory block which causes the problems just described.
Thus you could make two CED synonyms as follows. (We assume that
the CED "chain character" is ^).
SYN LOADSK mark !sk^sk
{make a protected sidekick marker and load sidekick}
SYN RUNLOT release !sk^lotus^mark !sk^sk
{release sidekick if it's there, run lotus, then reload sidekick}
================================================================
As of version 2.0, a new form of marking, called a "file
mark", is also supported. The new mark has the advantage that it
uses only about 150 bytes of memory rather than the 1600 of MARK.
The new mark is placed with the command
FMARK [d:][directory]filename
The bulk of the vector table and EMS page map are stored in the
file which you specify on the command line rather than in
memory. Note that a command line parameter is *required* in this
case. Otherwise FMARK will halt with an error. The file created
by FMARK will be between 1000 and 2000 bytes in size, depending
on usage of expanded memory.
If you might switch drives or directories after using FMARK, you
should specify a complete pathname when FMARK is initially
called. To avoid confusion, you may want to keep the FMARK files
in the root directory, or in a separate directory defined just
for this purpose.
The RELEASE program has been upgraded so that it can release
either an in-memory mark (placed by MARK.COM) or a file mark
(placed by FMARK.COM). Use of RELEASE with in-memory marks is
the same as before. To use RELEASE with file marks, call it with
the name of the mark file on the command line:
RELEASE [d:][directory]filename
Note that in this case the filename must be specified on the
command line, and that only a file mark exactly matching the
command line will be released. If the specified mark file is not
found, RELEASE will halt with an error message. When the memory
is released, the mark file is also deleted from disk.
There is no direct equivalent of protected marks for FMARK. If
an unnamed RELEASE finds an in-memory mark below a file mark,
the file mark will be released in the process of the unnamed
release. In this case, the mark file will not be deleted from
disk.
================================================================
Version 2.1 of RELEASE fixes a stupid bug in 2.0. This bug lead
to reports of RELEASE printing its status message on the
printer, and to some system crashes. The bug was caused by
writing over the first two bytes of the DOS file handle table at
offset 0018H in the PSP.
We have become aware that certain resident programs which
support the EGA change certain memory locations in the BIOS data
area (0040:XXXX) when they go resident. RELEASE does not restore
these locations, so unpredictable events may occur upon
releasing them. A future version of TSR will handle this effect.
B. MAPMEM
================================================================
MAPMEM.COM is used to display the current DOS memory map. It shows
the resident programs, how much memory they use, and what interrupt
vectors each currently owns. MAPMEM also shows information about
expanded memory when such a driver is installed. MAPMEM writes to
the standard output - thus the output can be printed or stored
to a file.
Calling MAPMEM with a "V" command line parameter (i.e., MAPMEM /V)
will show additional information about each memory block. MAPMEM
will also accept V or -V as the command line switch for the
"verbose" option. The "Files" column shows the number of file
handles that each resident block has kept open. Each block of
memory reported by DOS is listed individually in verbose mode.
This is useful in debugging problems, either with the TSR package
itself, or perhaps with the resident programs that you are using.
MAPMEM shows MARKs and FMARKs so that you can look at them prior
to a RELEASE. A MARK will show the owner name "MARK", and the
mark name (if any) in the command line area. An FMARK will show
"N/A" in the owner column (due to the minimal memory kept by an
FMARK), and the name of the mark file in the command line area.
Everything we know about DOS memory allocation is embodied in
the source code for MAPMEM and RELEASE. We found this out by
piecing together tips from friends and through many hours of
snooping. Please don't call for an explanation.
C. RAMFREE and EATMEM
================================================================
RAMFREE.COM supplies a quick way to determine the amount of free
RAM (without going through CHKDSK). RAMFREE also reports the
segment at which the free memory block begins.
EATMEM.COM is useful for program development work when you want
to test software in an environment with a desired amount of
available memory. Note that the memory used by EATMEM can be
freed up by using MARK and RELEASE. EATMEM is called with a
single command line parameter, specifying the (decimal) number
of KILOBYTES to eat up:
EATMEM KiloBytesToEat
Note that EATMEM will happily allow you to eat up all system
memory, leading to a crash when COMMAND.COM cannot be reloaded.
Be sure to calculate how much memory to eat before calling
EATMEM.
D. The Story Behind the TSR Utilities
================================================================
These programs should work on any system running PCDOS or
MSDOS 2.0 or later. They were developed on a Compaq Deskpro 286
running Compaq DOS 3.0 and have subsequently been tested on a
number of different systems. Complete source code is available
in the file TSRSRC.ARC. MARK, FMARK, RAMFREE and EATMEM are
written in assembly language (CHASM), while MAPMEM and RELEASE
are written in Turbo Pascal. TSRSRC requires that you have Turbo
Pascal version 3. On CompuServe, TSRSRC is found in the Borland
SIG (Go BOR-100) in data library 1 (DL1).
The programs have been released to the public domain for personal,
non-commercial use only. You may use them yourself, give them to
your friends or co-workers, or distribute them for a cost-based
fee as part of a user's group or bulletin board service. If you
wish to distribute these programs as part of a commercial package,
please contact us for a license agreement.
These programs were originally developed as an exercise in
understanding DOS memory management. They have been put in the
public domain as a public service. We ask for no donation for
this set of programs. If for some reason you want the latest
version or need support, we will ask for $5 to cover the costs
of shipping a new disk to you.
TurboPower Software is in the business of Turbo Pascal
programming tools for serious developers. Our first product, the
TurboPower Utilities, contains 9 programs including an
intelligent cross-reference, a pretty printer, an execution
profiler and several DOS file and text management tools. Our
second product, Turbo EXTENDER, lets Turbo Pascal programs grow
beyond 64K bytes in size via modular compilation and linking. It
also provides a toolbox of routines for virtual array management
and disk caching, as well as analytical tools for overlayed
programs. As of this writing, we are preparing to release a
powerful symbolic debugger for Turbo Pascal. Tdebug-PLUS will be
an expanded and fully supported version of the popular public
domain program TDEBUG. It will include both a fully symbolic
facility integrated with the Turbo development environment, and
also the ability to generate DOS standard MAP files for use with
other external symbolic debuggers such as Periscope, Symdeb, and
Atron.
The TSR Utilities were written by Kim Kokkonen, with thanks to
Neil Rubenking for the original idea behind MARK and RELEASE.
Also my thanks to Richard Wilson and Barry Simon at Cal Tech for
the idea that lead to FMARK, and much useful correspondence
about the TSR Utilities.
We can be reached at:
TurboPower Software
3109 Scotts Valley Drive #122
Scotts Valley, CA 95066
408-438-8608
Compuserve: 72457,2131
Version 2.1 - 7/18/86.