Der Mediaplex Sampler - Die 6 von Plex/6_v_plex.zip/6_v_plex/DISK5/DOS_41/TSR32.ZIP/TSR.DOC

Text File | 1991-11-22 | 52KB | 1,190 lines

                        TSR Utilities Version 3.2
                             Kim Kokkonen
                          TurboPower Software
                               11/22/91

Table of Contents
---------------------------------------------------------------------
1. Introduction
2. MARK, FMARK, and RELEASE
3. MARKNET and RELNET
4. WATCH and DISABLE
5. MAPMEM, RAMFREE, and DEVICE
6. EATMEM
7. Known Limitations
8. Version History
9. Copyright and License Information

1. Introduction
---------------------------------------------------------------------
The TSR Utilities are a collection of programs useful for managing DOS
memory, particularly for managing memory-resident programs, also known
as TSR's. TSR stands for "Terminate and Stay Resident". The most
popular use of these utilities is for removing TSR's from memory
without rebooting the PC. There are many other uses, however,
especially if you are a software developer.

The TSR Utilities have grown to include 11 programs. Here's a quick
overview of each one:

  MARK     marks a position in memory above which TSR's can be
           released.
  RELEASE  removes TSR's from memory.
  FMARK    performs the same function as MARK but uses less memory.
  MARKNET  like MARK, but saves a more complete picture of system
           status.
  RELNET   removes TSR's marked with MARKNET.
  WATCH    a TSR itself, it keeps records of other TSR's.
  DISABLE  disables or reactivates TSR's, leaving them in memory.
  RAMFREE  shows how much RAM memory is available.
  MAPMEM   shows what memory resident programs are loaded.
  DEVICE   shows what device drivers are loaded.
  EATMEM   uses up memory for controlled program testing.

These programs are described in detail in the following sections. If
you haven't used them before, be sure to read the documentation: All
of the programs are command line driven, and unexpected events may
occur if you just start typing the program names at the DOS command
line. Also be sure to read section 7, "Known Limitations".

The most notable feature of TSR Utilities version 3.0 is support for
MS-DOS 5.0 and TSR's loaded in high memory. If you're familiar with
previous versions of the TSR Utilities, see the file TSR30.DOC for a
summary of the changes in version 3.0. Version 3.1 cleans up bugs and
compatibility problems discovered in 3.0. Version 3.2 of the utilities
generalizes the high memory support, so that it no longer requires DOS
5.0 or particular memory manager versions.


2. MARK, FMARK, and RELEASE
---------------------------------------------------------------------
MARK.COM and RELEASE.EXE are used to remove TSR's from memory, without
requiring a system reboot. In their simplest form, MARK and RELEASE
are used as follows:

1. Run MARK before installing your TSR(s). This marks the current
position in memory and stores information that RELEASE will later need
to restore the system. A common place to call MARK is in your
AUTOEXEC.BAT file.

2. Install whatever TSR's you want, using the normal method for each
TSR.

3. To remove those TSR's from memory, run RELEASE. This will release
all of the memory above (and including) the last MARK, and will
restore the system to the state at the time the MARK was made.

There are a number of variations of this simple method. If you want to
release TSR's loaded in high memory, be sure to read the remainder of
this section for instructions on how to do so.

MARKs can be stacked in memory, as shown in the following hypothetical
batch file:

    MARK
    TSR1
    MARK
    TSR2
    MARK
    TSR3

Each call to RELEASE releases memory above and including the last
MARK. In this example, the first call to RELEASE would remove TSR3 and
the last MARK from memory, the second call would remove TSR2 and its
MARK, and so on.

MARK and RELEASE may be called using a command line parameter. The
parameter specifies a "mark name" and allows releasing TSR's to a
specific point in memory. Consider the following example:

    MARK TSR1
    TSR1
    MARK TSR2
    TSR2
    MARK TSR3
    TSR3

This loads the three TSR's just as in the previous example. However,
if RELEASE were called like this,

    RELEASE TSR2

then both TSR2 and TSR3 would be removed from memory. Note that the
use of such a name does not allow just a single layer of TSR's to be
removed (just TSR2, for example). RELEASE always removes all TSR's
including and beyond the one named.

A mark name is any string up to 126 characters long. The name may not
include white space (blanks or tabs). Case (upper or lower) is not
significant when matching mark names.

When named marks are used as in this example, calling RELEASE without
specifying a mark name will still remove the last TSR from memory.
Assuming that TSR1, TSR2, and TSR3 were still in memory, typing just
RELEASE would remove TSR3 and the last mark. It is possible to change
this behavior by using "protected marks", which can be released only
by explicitly specifying their names. A protected mark is placed by
giving it a name that starts with an exclamation point, '!'. Consider
the following:

    MARK TSR1
    TSR1
    MARK TSR2
    TSR2
    MARK !TSR3
    TSR3

Here !TSR3 specifies a protected mark. Typing just RELEASE would
produce an error message "No matching marker found, or protected
marker encountered". The same error would occur after entering the
command RELEASE TSR2. When this error occurs, RELEASE does not remove
any TSR's from memory.

The only way to remove TSR3 in this case is by entering

    RELEASE !TSR3

Each time a MARK is placed in memory, it consumes about 1600 bytes of
RAM space, which is used to store a copy of the system interrupt
vector table and other information with which RELEASE can later
restore the system. Although 1600 bytes isn't very much, we can reduce
this memory usage by storing the information in a disk file rather
than in memory. FMARK.COM is a variation on MARK that does just that.
You can call FMARK at any time that you would call MARK. FMARK uses
only about 150 bytes of memory.

All calls to FMARK must include a command line parameter to specify
the name of the file:

    FMARK [d:][directory]filename

You should generally specify a complete pathname for the mark file.
When you later call RELEASE, you must give it the identical pathname,
regardless of what the current directory happens to be at the time.
For example, if you specified the following file mark

    FMARK C:\TEST\TEST.MRK

then the following calls to RELEASE would generate an error,

    RELEASE TEST.MRK
    RELEASE C:TEST.MRK

even if the current directory on drive C: was \TEST. The only way to
call RELEASE is with

    RELEASE C:\TEST\TEST.MRK
or
    release c:\test\test.mrk

RELEASE can use either type of mark: in-memory or on-disk. Note that
file marks placed by FMARK are never treated as protected marks,
although of course their names must be passed to RELEASE in order to
remove them directly.

Consider the following example:

    MARK TSR1
    TSR1
    FMARK C:\MARKS\TSR2.MRK
    TSR2

Typing just RELEASE in this situation generates the warning message
"No matching marker found, or protected marker encountered", because
the file mark's name has not been provided.

TSR2 can be removed from memory by entering

    RELEASE C:\MARKS\TSR2.MRK

RELEASE deletes the mark file when it has finished.

Alternatively, TSR2 and TSR1 could be removed at the same time by
typing

    RELEASE TSR1

MARK may be called with one optional command line parameter:

    /Q         write no screen output. (-Q means the same.)

The /Q option is useful when you are using MARK in an integrated
system. Redirecting MARK's output may waste system file handles and
should never be done.

RELEASE has several command line options to modify its behavior. The
following table lists the options, which must start with a slash, '/',
or a hyphen, '-'.

    /E         do NOT access EMS memory.
    /K         release memory, but keep the mark in place.
    /Q         write no screen output.
    /S chars   stuff string (<16 chars) into keyboard buffer on exit.
    /U         consider upper memory blocks for release.
    /?         write this help screen.

None of the options is required for normal use of RELEASE.

/E is made available for systems running early, buggy EMS (expanded
memory) drivers that don't correctly implement all of the EMS 3.2
system calls. Don't use it unless you have an EMS-related problem
during or after running RELEASE.

/K is useful when you will be releasing and reloading a TSR
repeatedly. With it, you avoid the need to replace the mark each time
the TSR is released. Using /K in combination with a file mark also
prevents RELEASE from deleting the mark file.

/Q prevents RELEASE from writing any screen output (unless an error
occurs). This is useful when you are using RELEASE in an integrated
system. Note that redirecting RELEASE's output causes technical
problems and should not be done.

/S followed by at least one space and then a short string (15
characters or fewer) tells RELEASE to stuff this string into the
keyboard buffer just before exiting. RELEASE automatically adds a
carriage return to the end of the string. The string may not contain
tabs or spaces.

To explain why the /S option is important, we must digress a moment.
Let's assume that you normally keep SideKick loaded, but that you must
unload it in order to have enough memory free to run Lotus 1-2-3. It
would seem reasonable to write a little batch file like this:

   RELEASE SK
   LOTUS
   MARK SK
   SK

which would remove the previously loaded SideKick from memory, run
Lotus, and then load SideKick again. Unfortunately, this doesn't work!

The reason is complicated to explain. It must suffice here to say that
DOS batch files trap memory, and the memory freed by a call to RELEASE
does not truly become available until the current batch file ends.

Now perhaps the need for the /S option becomes clear. We can split the
previous batch file into two:

  batch1:
    RELEASE SK /S BATCH2

  batch2:
    LOTUS
    MARK SK
    SK

The first batch file releases the memory and stuffs the characters
'BATCH2<Enter>' into the keyboard buffer. When the batch file ends,
the released memory becomes available. DOS automatically reads the
keystrokes waiting in the buffer and starts up the second batch file,
which runs Lotus and later reloads SideKick.

To keep things simple, the /S option pokes the specified keystrokes
directly into the system keyboard buffer. As a result, the number of
keystrokes is limited to 15 (not counting the <Enter> key, which
RELEASE adds automatically). This always allows enough keys to start
another batch file, however, and the new batch file can take over from
there.

RELEASE detects when it is releasing memory within a batch file. It
writes a warning message to that effect, but continues processing
anyway under the assumption that the batch file is about to end. You
can ignore the warning if you've already taken account of DOS's memory
management behavior within batch files.

The /U option is required when you are releasing a TSR that has been
loaded into high memory (memory between 640K and 1 megabyte). It may
be also appropriate even for a TSR loaded into low memory, if other
TSR's have been loaded into high memory.

The high memory features of TSR Utilities version 3.0 are available
only if you are running a compatible memory manager. Any memory
manager that supports the UMB (upper memory block) features of XMS
(extended memory specification) memory managers should work with the
high memory features of the TSR Utilities. This includes 386MAX
(Qualitas), QEMM386 (Quarterdeck), HIMEM/EMM386 (Microsoft), and
HIDOS/EMM386 (Digital Research).

If you're using just the high memory features of MS-DOS 5.0 itself,
without additional memory managers, note that you must have at least
the following in your CONFIG.SYS in order for the TSR Utilities to
access high memory:

  DEVICE=HIMEM.SYS
  DEVICE=EMM386.SYS RAM
  DOS=UMB

See the discussion of the EMM386.SYS driver in your MS-DOS 5.0
documentation for more information about options compatible with
creating upper memory blocks.

With other memory managers such as QEMM and 386MAX you should *not*
put the DOS=UMB statement in CONFIG.SYS. (This is a change from
versions 3.0 and 3.1 of the TSR Utilities.)

To test whether your memory manager is compatible with the TSR
Utilities high memory features, try entering MAPMEM /U at the DOS
command line. If you get a high memory report from MAPMEM, then you
can assume that the memory manager is compatible with TSR Utilities
3.0. Because of the lack of complete standards for managing high
memory, the names and attributes of programs in high memory may
sometimes appear garbled: unfortunately there is little we can do
about this without building features specific to particular memory
managers into the TSR Utilities.

Note that even if you don't get a high memory report from MAPMEM, you
can still use the TSR Utilities 3.0 without upper memory support.

The /U option causes a fundamental change in the behavior of RELEASE.
It is important that you understand what it does in order to use it
properly.

When the /U option is *not* specified, RELEASE removes programs in
address order. That is, with a few exceptions, it deallocates any
memory blocks that have a memory address greater than or equal to that
of the mark.

This behavior is almost never appropriate when TSR's are loaded high.
When high memory is involved, the *chronological* order in which TSR's
were loaded rarely matches the *address* order in which they were
loaded. Before TSR's could be loaded high, these two orderings were
usually the same, so no distinction was necessary. Now, however, it's
common to load one program high, then one low, then another high; or
to load one program into "region 2" of high memory, then another into
"region 1", and so on.

Therefore, when the /U option is activated, RELEASE frees memory in
*chronological* order. That is, it frees all memory blocks allocated
since the time the mark was placed, regardless of the address position
of the memory. Additional information is now stored in the mark file
or memory image to allow this to occur. Only when /U is specified does
RELEASE access high memory.

If you have *any* TSR's loaded into high memory, you should use the /U
option, even if the particular TSR you're unloading is located in low
memory. Depending on the chronological order in which you loaded the
TSR's, an unload from low memory may also trigger unloads from high
memory, or vice versa.

When you intend to use the /U option, you must provide a unique mark
name for each mark (because there is no unambiguous way to find the
correct unnamed mark). Note that a mark name is inherent in the
filename specified to FMARK.

Because of the chronological nature of RELEASE /U, you can load the
MARK high and the associated TSR low (or vice versa) if desired.

Technical note: due to the lack of comprehensive standards for
managing high memory, the TSR Utilities must use a heuristic technique
for finding the first block of high memory. They search on each
paragraph boundary starting at the top of normal memory (normally
0A000h) for the character 'M', which is always found at the beginning
of a valid memory control block. Then, using this location as the
starting point, they trace the block chain searching for a terminating
'Z' block. If no 'Z' block is found, they start searching again at the
paragraph beyond the previously found 'M' block. This requires that at
least two blocks be already allocated in high memory (an 'M' block and
a 'Z' block); we haven't found any cases where this is a practical
limitation. Overall, the heuristic technique appears to be reliable
with the common high memory managers, and has the advantage that it
doesn't count on unique features of any one of them.

The high memory features of the TSR Utilities count on the "link UMB"
feature of DOS 5 being turned off. When link UMB is on, normal RAM and
high memory are linked together into a single chain of memory control
blocks, and in this case the heuristic technique used by the utilities
would cause the blocks in high memory to be processed twice.
Fortunately, we don't know of any cases where "link UMB" is activated
by DOS application programs except temporarily during times when the
TSR Utilities could not possibly be used.


3. MARKNET and RELNET
---------------------------------------------------------------------
Use of these utilities is very similar to that described in the
preceding section. MARKNET is analogous to FMARK, and RELNET is like
RELEASE. MARKNET stores more information about the system's status
than does MARK, so it is appropriate for managing TSR's, such as
network shells, that hook into the system at a low level.

Because MARKNET stores so much information about the system, it always
writes the data to a disk file in order to reduce its own memory
usage.

Command line syntax for MARKNET and RELNET is:

  MARKNET [d:][directory]filename [/Q]
  RELNET  [d:][directory]filename [options]

The main command line parameter to each program specifies the name of
the file where the mark information will be stored. We refer to this
file as the net mark file. A complete pathname should be specified for
the net mark file. RELNET's pathname must exactly match that passed to
MARKNET, with the exception of case.

Note that MARKNET and RELNET may be used in almost any situation where
FMARK and RELEASE are used. MARKNET saves all of the same system
information as does FMARK, but it goes further to store information
such as the device driver chain, DOS internal variable areas, DOS
system file tables, DOS environment, communications port status, XMS
memory state, and other information. Nevertheless, MARKNET and RELNET
were written primarily because of the large demand to release the
NetWare shell. We'll refer to NetWare specifically in the following
and provide an example of how to load and release it.

The only new restriction for using MARKNET is that the system must be
running DOS version 3.0 or later. MARKNET depends on the format of
certain internal DOS data structures that were quite different in DOS
version 2.

Like FMARK, MARKNET leaves a small (144-192) byte mark in memory, and
writes a disk file to store the system status. MARKNET's file varies
in size, but is typically 3-4K bytes. The size depends on the number
of device drivers, the value of the 'FILES=' directive in CONFIG.SYS,
the number of EMS and XMS memory blocks allocated, and other DOS
implementation details.

Do not attempt to redirect the output of MARKNET. Doing so will waste
at least one file handle that cannot be recovered later by RELNET.
MARKNET's /Q option is provided to prevent it from writing any screen
output.

Marks placed with MARK, FMARK, and MARKNET may be mixed in the same
system. RELEASE treats all marks placed with MARKNET as protected;
such marks may be released only by calling RELNET explicitly. Consider
the following example:

  MARK TSR1
  TSR1
  FMARK C:\MARKS\TSR2.MRK
  TSR2
  MARKNET C:\MARKS\TSR3.MRK
  TSR3

Entering RELEASE by itself would generate a warning and do nothing
else. Entering RELEASE C:\MARKS\TSR2.MRK would generate the same
warning. The only way to get all three of these TSR's out of memory
would be to enter the following commands in sequence:

  RELNET C:\MARKS\TSR3.MRK
  RELEASE C:\MARKS\TSR2.MRK
  RELEASE TSR

RELNET has options to control how much of the system state it
restores. Several of the options match those of RELEASE; new ones are
also provided to control the additional information that MARKNET
stores. RELNET accepts the following options:

  /C        do NOT restore the communications ports.
  /E        do NOT access EMS memory.
  /I        do NOT shut down IPX events and sockets.
  /K        release memory, but keep the mark in place.
  /P        do NOT restore DOS environment.
  /Q        write not screen output.
  /R        revector 8259 interrupt controller to powerup state.
  /S chars  stuff string (<16 chars) into keyboard buffer on exit.
  /T        do NOT reset the system timer chip.
  /U        consider upper memory blocks for release.
  /V        verbose: show each step of the restore.
  /X        do NOT access XMS memory.
  /?        write help screen.

None of these options, except perhaps /U, is required in order to
release the NetWare workstation shell.

/C prevents RELNET from restoring the communications state of the
system (as encoded in the 8250 async chip and the 8259 programmable
interrupt controller). Because both of these chips provide readable
registers, MARKNET is able to store an accurate picture of the
communications state when the mark is stored; RELNET can restore the
state to exactly what it was. Therefore, the /C option should be
needed rarely, perhaps only on newer PS/2 models that don't use the
8250 as a communications controller. Note that MARKNET stores
information only about COM1 and COM2.

/E is made available for systems running early, buggy EMS drivers that
don't correctly implement all of the EMS 3.2 system calls. Don't use
it unless you have an EMS-related problem during or after running
RELNET.

/I prevents RELNET from detecting and deactivating IPX events and
sockets owned by the memory blocks being released. (IPX is the low
level communications protocol used on Novell networks.) Don't use it
unless it solves a problem for you.

/K is useful when you will be releasing and reloading a TSR
repeatedly. With it, you avoid the need to replace the mark each time
the TSR is released. Using /K prevents RELNET from deleting the net
mark file.

/P keeps RELNET from restoring the DOS environment, which it normally
does because NetWare modifies the DOS PATH. In some cases, other
changes to the environment should not be undone; use the /P switch
only when such changes must be preserved.

/Q prevents RELNET from writing any screen output (unless an error
occurs). This is useful when you are using RELNET in an integrated
system. Redirecting RELNET's output causes technical problems and
should never be done.

/R may be useful for unloading task-switching utilities that
"revector" the hardware interrupt controller. Use it only if it solves
a problem.

/S followed by at least one space and then a short string (15
characters or fewer) tells RELNET to stuff this string into the
keyboard buffer just before exiting. RELNET automatically adds a
carriage return to the end of the string. The string may not contain
tabs or spaces. See the discussion of /S in the preceding section for
more details.

/T keeps RELNET from resetting the system timer chip to its default
rate, which it does by default.

/U allows RELNET to access high memory. See the discussion of high
memory in the previous section for more information.

/V activates additional status reporting during the release and may
provide useful information in cases when RELNET isn't working.

/X prevents RELNET from restoring the state of XMS (extended) memory.
This option is provided in case of an unforeseen conflict with an XMS
memory driver.

The following is a simple version of a NetWare LOGIN.BAT file with
support for releasing the shell:

  rem place the mark
      marknet C:\NET\NETWARE.MRK

  rem load the NetWare shell TSR's
      ipx
      net3
  rem optional portions of the shell
  rem netbios
  rem int2f

  rem switch to login drive and log in
      F:
      login USERNAME

At a minimum, the items in uppercase will need to be customized for a
given user and workstation.

NetWare could then be released with the following batch file:

  rem let the server know we're leaving
      z:\public\logout
  rem restore the workstation
      relnet C:\NET\NETWARE.MRK

As of TSR Utilities version 3.0, you may release the NETBIOS emulator
independently from NETx and IPX. You should always release NETx and
IPX together.


4. WATCH and DISABLE
---------------------------------------------------------------------
WATCH.COM is a memory-resident program that keeps track of other
memory resident programs. As a TSR goes resident, WATCH updates a data
area in memory that contains information about what interrupt vectors
were taken over. This information can later be used by MAPMEM and
DISABLE to show more details about interrupts than normally available.

Installation of WATCH.COM is optional. All of the TSR Utilities except
DISABLE can be used whether or not WATCH is installed.

If you want to use it, WATCH.COM should be installed as one of the
first TSR's in your AUTOEXEC.BAT file. WATCH may be loaded into low
memory or, if a compatible memory manager is in use, into high memory.

WATCH uses about 3100 bytes of memory when it is installed. Most of
this memory holds various information about the TSR's installed in the
system -- it includes a copy of the interrupt vector table and a data
area containing a list of the interrupt vectors taken over by each
TSR. This information is used by DISABLE to deactivate and reactivate
TSR's without removing them from memory. It is also used by MAPMEM to
report more accurately on the interrupt vectors trapped by each TSR.

With DISABLE.EXE, you can disable and reenable specified memory
resident programs without removing them from memory. Its function is
analogous to that performed by REFEREE from Persoft, although DISABLE
has neither a fancy user interface nor an option to work from within
other programs. DISABLE can allow conflicting TSR's to coexist, and it
can let you run applications whose keystrokes conflict with those of
TSR's already loaded. DISABLE also provides a small bonus in that it
can be used to detect the presence of a particular TSR in memory, thus
allowing the design of semi-intelligent batch files. (Note that, as of
version 3.0, MAPMEM also can detect the presence of a particular TSR,
without requiring that WATCH be loaded.)

In order to use DISABLE, you must install WATCH.COM prior to loading
any TSR that you wish to disable. WATCH keeps the detailed information
about each memory resident program that DISABLE uses to later control
them.

Like the other TSR Utilities, DISABLE is operated from the command
line. You specify a single TSR by its name (if you are running DOS 3.0
or later) or by its address as determined from a MAPMEM report
(described below). If you specify an address, immediately precede the
address with a dollar sign "$" and specify the address in hexadecimal.

The name specified for a TSR is the one reported by MAPMEM in the
"Name" column. If this column reports "n/a", then you must instead
specify the address from the "PSP" column.

DISABLE accepts the following command line syntax:

  DISABLE TSRname|$PSPaddress [options]

Options may be preceded by either / or -. Valid options
are as follows:

     /A     reactivate the specified TSR.
     /C     check for the presence of the specified TSR.
     /O     disable the TSR even if dangerous (Override).
     /Q     write no screen output.
     /U     work with upper memory blocks.
     /?     write a help screen.

If no option is specified, DISABLE will disable the named TSR. When /A
is specified, a previously disabled TSR is reenabled.

/C causes DISABLE simply to check for the presence of a TSR. It writes
an appropriate screen message and returns a DOS ERRORLEVEL to indicate
whether the TSR is currently in memory: 0 if the TSR is present, 2 if
it is not present, 254 or higher if an error occurs.

/O allows DISABLE to proceed with disabling a TSR even if internal
checks indicate that it isn't safe to do so. Use this option only
after careful experimentation indicates that it is safe to do so.

/Q prevents DISABLE from writing any screen output. DOS ERRORLEVEL is
still set to allow batch files to determine the results.

/U allows DISABLE to access upper memory blocks. You cannot disable a
TSR loaded high without using this option. As with RELEASE and RELNET,
you must have a compatible memory manager in order to use the DISABLE
/U option. See section 2 for more information.

DISABLE sets the DOS ERRORLEVEL in order to return status information
to a batch file. It uses the following values of errorlevel:

  0       success: TSR is present, was disabled, or was reenabled.
  1       TSR is present, but no action was required to enable or disable it.
  2       TSR is not present in memory.
  254     invalid command line.
  255     severe error.

Examples of using DISABLE:

  DISABLE SK              disables SideKick
  DISABLE SK /A           reenables SideKick
  DISABLE SK /C           checks for the presence of SideKick
  DISABLE SK /A /U        reenables SideKick when it was loaded into
                          high memory
  DISABLE $2F2E           disables the TSR at address 2F2E (hex)


5. MAPMEM, RAMFREE, and DEVICE
---------------------------------------------------------------------
These three utilities provide status information about DOS memory
usage. They don't make active changes to the system like RELEASE and
DISABLE do.

MAPMEM.EXE displays a map of DOS memory. It shows the resident
programs, how much memory they use, and what interrupt vectors each
one controls. MAPMEM also shows information about expanded and
extended memory when available.

MAPMEM writes to the standard output -- hence, the output can be
printed or stored to a file by using DOS redirection.

Here is an example of MAPMEM output:

MAPMEM 3.2, Copyright 1991 TurboPower Software

Psp  Cnt   Size Name       Command Line        Hooked Vectors
---- --- ------ ---------- ------------------- ----------------------
      2  74,704 DOS
1240  2   3,296 4DOS                           2E
      1      80 ---free---
1316  1     464 MODE
133B  2   9,216 DESKPOP    /k /x /1            05 08 09 13 16 25 26 28
157F  2   3,296 TPE                            1B
164F  3   3,328 4dos       /e /x /u            22 23 24 2F
1722  2 560,736 ---free---
        655,360 ---total--

EMS Memory
0000     16,384 n/a
        770,048 ---free---
      1,048,576 ---total--

XMS Memory
0001    409,600 n/a
0002    266,240 n/a
0003     73,728 n/a
0004    568,320 n/a
0005     22,528 n/a
         35,840 ---free---
      1,376,256 ---total--

"Psp" stands for Program Segment Prefix. This is the physical address,
specified in hexadecimal, where the program was loaded. If you're
running DOS 2.x, you'll need to use an address from this column to
pass to DISABLE.

"Cnt" is the number of memory blocks DOS is using to manage the
program. This will typically be two: one for the program itself and
another for the environment that stores the program name, the DOS
path, and other environment variables.

"Size" is the number of bytes of memory, specified in decimal,
allocated to the program.

The "Name" column shows the name of the program that allocated the
block. An "n/a" in this column means either that the program
deallocated its environment to reduce memory usage or that the system
is running DOS 2.x, where the owner names are simply not available.
Note that, under MS-DOS 5.0, an alternate method allows MAPMEM to find
the TSR name even if it deallocated its environment.

"Command line" shows the command line entered when the TSR was
originally loaded. Some TSR's overwrite their command line with other
code or data in order to save memory space. MAPMEM can usually detect
this behavior and will display "n/a" in the command line column when
it does.

The last column will be titled as either "Chained vectors" or
"Hooked vectors". When WATCH is loaded, "Chained" will appear;
otherwise, "Hooked" will. The numbers in this column indicate what
interrupt vectors the TSR has grabbed. Without WATCH, MAPMEM must use
a heuristic technique to identify the owner of each vector; don't be
surprised if you see some ridiculous looking vector numbers. With
WATCH, MAPMEM should report an accurate list for each TSR, and should
show the complete chain of control for each interrupt.

MAPMEM indicates disabled TSR's by displaying the word "disabled" in
the interrupt vector column of the report.

MAPMEM displays free memory blocks with the notation "---free---", and
the total amount of memory in a particular region with the notation
"---total--".

On systems running a compatible memory manager, MAPMEM will also
contain a section reporting memory used in the region between 640K and
1 megabyte. This section is interpreted just like the one for lower
memory. Because of the lack of complete standards for managing high
memory, the names and attributes of programs in high memory may
sometimes appear garbled: unfortunately there is little we can do
about this without building features specific to particular memory
managers into the TSR Utilities.

The expanded memory report shows each allocated block of expanded
memory, as well as the free and total EMS space. If a program has
assigned a name to an EMS memory block, that name will appear adjacent
to the block size.

Similarly, when an XMS (extended) memory driver such as HIMEM.SYS is
loaded, MAPMEM reports the blocks of allocated extended memory. A name
is never available for XMS memory.

If extended memory is available and no HIMEM driver is loaded, MAPMEM
will report the free and total amount of raw extended memory. These
numbers can be misleading because some applications allocate extended
memory by making it appear that the memory is no longer installed on
the system.

MAPMEM offers the following command line options:

     /C name  check whether TSR "name" is loaded.
     /E       report expanded (EMS) memory.
     /F       report free areas only.
     /H       do not use WATCH information for vectors.
     /Q       write no screen output with /C option.
     /S       show summary of all memory areas.
     /U       report upper memory blocks.
     /V       verbose report.
     /X       report extended (XMS) memory.
     /?       write this help screen.

When /C is specified, MAPMEM does not produce its normal report.
Instead, it simply checks to see whether the named TSR is currently in
memory. MAPMEM then writes an appropriate screen message, and also
sets the DOS ERRORLEVEL so that a batch file can detect the results.
MAPMEM returns errorlevel 2 if the TSR isn't loaded, 1 if there was a
syntax error, and 0 if the TSR is in memory. Note that this option
does *not* require WATCH to be loaded.

/E causes MAPMEM to generate its expanded memory report.

/F causes MAPMEM to report just the free areas in normal, high,
expanded, and extended memory.

/H causes MAPMEM to report "hooked" vectors, even if WATCH is loaded.

/Q prevents MAPMEM from writing any screen output. This option is only
meaningful in combination with the /C option.

/S generates a "summary" report. The report shows just the size, name,
and command line of each program in conventional memory, including any
free blocks. It also shows the free and total memory for EMS and XMS.

/U causes MAPMEM to write information about MS-DOS 5.0 high memory
(upper memory blocks).

/V generates a verbose report instead of the standard report about
normal and high memory. In this case, MAPMEM shows each individual
memory block rather than just one for each program. It also adds two
new columns of information. "Mcb" stands for Memory Control Block.
This is a physical address, expressed in hexadecimal, of the DOS data
structure used for managing each block of memory. The MCB address is
typically one less than the address of the program. "Files" reports
the number of files kept open by the TSR. In most cases this will be
zero, in which case the corresponding column of the report is left
blank. When it is non-zero, the maximum number of files opened by the
rest of the programs (including the foreground application) is reduced
accordingly.

When /V is active, MAPMEM also reports the memory allocation of each
DOS device driver under DOS 5. It also shows details of memory
associated with the interrupt vector table, the BIOS data area, and
various DOS data areas.

RAMFREE.COM is a tiny program with a single purpose: to tell you how
many bytes of memory are free for the next application. The number it
reports is the same as that reported by (some versions of) the DOS
CHKDSK utility. RAMFREE's advantage is that you don't need to wait for
your hard disk to be analyzed before you find out how much memory is
free.

DEVICE.EXE reports on device drivers installed by the CONFIG.SYS file.
It shows the memory used by DOS itself, any additional drivers
installed in CONFIG.SYS, and the space used for DOS file handles and
buffers. Here is a simple example of DEVICE output:

 Address     Bytes   Name           Hooked vectors
---------   ------   -------------- --------------
0070:0BB3        -   CON
0070:0C68        -   AUX
0070:0C7A        -   COM1
0070:0D17        -   PRN
0070:0D29        -   LPT1
0070:0E15        -   CLOCK$
0070:0EE5        -   3 Block Units
0070:2071        -   LPT2
0070:2083        -   LPT3
0070:2095        -   COM2
0000:2C58    37712   NUL            08 0A 0C 0D 0E 13 25 26 29 31 70 72
                                    73 74 75 76 77
09A5:0000     3488   0 Block Units
0A7F:0000       18   EMMXXXX0
0A7F:0012       46   386MAX$$       20
0A83:0000      768   1 Block Unit   19
0AB3:0000      768   1 Block Unit
0AE3:0000    18256   DOS buffers

The devices up to and including NUL are all part of DOS. DEVICE lumps
their memory usage into a single value next to the NUL device. The
memory usage associated with NUL does not include the interrupt vector
table, the BIOS data area, or the low-memory DOS data area. If you
wish to add this memory to the total, just take the hexadecimal
segment of the first driver you see (in this case CON) and multiply it
by 16 decimal. When the segment is 0070 as shown, that adds 1792 bytes
to the total space for DOS.

DEVICE also lumps all of the drivers up to NUL into a single block
when it comes to reporting hooked interrupt vectors. Because WATCH
can't be installed prior to these device drivers, DEVICE must use an
empirical technique to detect which vectors each driver controls.
Therefore, some meaningless vectors may appear in the list. Any
vectors that are grabbed by another program after the driver is loaded
will not appear.

"Block units" typically refer to disk drives. Any drivers that appear
after the NUL device are in the order that you've entered them in
CONFIG.SYS. Drivers loaded for non-standard hard disks, like
SpeedStor, sometimes make odd entries in the DEVICE report, as shown
with "0 Block Units" above. RAM disks appear more logically: each of
the "1 Block Unit" entries above is a VDISK with the data stored in
extended memory.

Devices like 386MAX may also cause odd-looking entries: 386MAX puts
most of its code in extended memory, and leaves just a bit behind in
normal memory.

DEVICE offers the following command line options:

     /R     raw report.
     /?     write a help screen.

The raw report shows more information about the device drivers, but in
a less convenient format. Here's an example, taken on the same system
as the previous report.

 Starting      Next             Strategy   Interrupt   Device
 Address     Hdr Addr   Attr   Entry Pnt   Entry Pnt   Name
---------   ---------   ----   ---------   ---------   --------
0000:2C58   0AB3:0000   8004   0000:14C6   0000:14CC   NUL
0AB3:0000   0A83:0000   0800   0000:00A9   0000:00D4   1 Block Unit
0A83:0000   0A7F:0012   0800   0000:00A9   0000:00D4   1 Block Unit
0A7F:0012   0A7F:0000   C000   0000:0036   0000:003B   386MAX$$
0A7F:0000   09A5:0000   8000   0000:0036   0000:003B   EMMXXXX0
09A5:0000   0070:0BB3   2000   0000:0012   0000:001D   0 Block Units
0070:0BB3   0070:0C68   8013   0000:00C6   0000:00D1   CON
0070:0C68   0070:0D17   8000   0000:00C6   0000:00D7   AUX
0070:0D17   0070:0E15   A040   0000:00C6   0000:00E6   PRN
0070:0E15   0070:0EE5   8008   0000:00C6   0000:010C   CLOCK$
0070:0EE5   0070:0C7A   0840   0000:00C6   0000:0112   3 Block Units
0070:0C7A   0070:0D29   8000   0000:00C6   0000:00D7   COM1
0070:0D29   0070:2071   A040   0000:00C6   0000:00EC   LPT1
0070:2071   0070:2083   A040   0000:00C6   0000:00F4   LPT2
0070:2083   0070:2095   A040   0000:00C6   0000:00FC   LPT3
0070:2095   0070:FFFF   8000   0000:00C6   0000:00DD   COM2

In this report, the drivers are listed in DOS priority order rather
than the order in which they are loaded in memory. Additional columns
describe how DOS treats each driver. Ray Duncan's book "Advanced
MS-DOS" is a good place to learn more about these details.

The DEVICE program assumes that all device drivers are loaded in the
CONFIG.SYS file. That is not the case with the NetWare shell, which
patches itself into the device driver chain. DEVICE will write a
warning message and terminate before reporting the first patched-in
driver. The raw device report will still show all of the devices even
in this case.


6. EATMEM
---------------------------------------------------------------------
EATMEM is a small program that is useful only to software developers.
It is a TSR that consumes a specified amount of memory. Developers can
use it to simulate a system with less memory, or to create a buffer
zone between an application and programs preceding it.

The memory used by EATMEM can be freed only by using MARK and RELEASE.

Call EATMEM with a single command line parameter, specifying the
(decimal) number of KILOBYTES to eat up:

  EATMEM KiloBytesToEat

For example, EATMEM 10 consumes 10K bytes of memory.

EATMEM will allow you to eat up all available memory, leading to a
system crash when COMMAND.COM cannot be reloaded. Be sure to calculate
how much memory to use before calling EATMEM.


7. Known Limitations
---------------------------------------------------------------------
RELEASE and RELNET are capable of removing many, but not all, TSR's
from memory. If you find that RELEASE doesn't successfully remove a
TSR, try RELNET instead. Even with RELNET, however, some TSR's cannot
be released without specific internal knowledge of the TSR. Since we
don't have (or care about) all such TSR's, RELEASE and RELNET may not
be compatible with them. If you find that RELNET won't release a TSR,
there is little we can do to help you.

The most common examples of TSR's that we can't be released are those
that cooperate with other TSR's in memory. Examples include
Microsoft's MOUSE driver and its associated MENU program; and the
program CED with its "user-installed commands" such as KEYIN, HS, RAW,
and others. These programs can be released, but only if all the
cooperating partners are released at the same time. CED is
well-behaved in that it provides a built-in command (KILL) to release
its partners. MOUSE is not so flexible, though.

Another problem TSR (and one that we hear about regularly) is the
Token Ring IPX driver for Novell NetWare. For some reason, IBM
designed this IPX driver in two pieces: one part that is loaded as a
device driver in CONFIG.SYS and another that is loaded as a TSR in
AUTOEXEC.BAT. RELNET does not release device drivers in general, and
it cannot release the TSR portion of the Token Ring driver without
also releasing the device driver portion.

You should almost never use RELEASE or RELNET to release disk caching
programs. If you do so, part of the information that should be stored
on disk will never be written there, and you may end up with a
corrupted disk as a result. If you know that the disk cache uses a
"write-through" algorithm (which guarantees that all writes
immediately go to disk), or if the disk cache has a "flush the cache"
command, then it may be safe to release the cache.

You cannot release the FASTOPEN and APPEND TSR's provided with DOS 3.3
and later. These TSR's patch internal DOS data areas that cannot be
reliably located even by MARKNET and RELNET.

You cannot use DISABLE to deactivate SideKick Plus, whose swapping
technique is incompatible with DISABLE.

For reasons we haven't been able to determine, when using the
combination of PC-DOS 4.00 and 386MAX 6.00 it isn't possible to reload
the NetWare NETX shell high after unloading it once using RELNET /U.
If you have this problem, we recommend that you toss your DOS 4.00 and
upgrade to MS-DOS 5.0.


8. Version History
---------------------------------------------------------------------
If you're converting to this version from version 2.5 or earlier, be
sure to delete RELEASE.COM, DISABLE.COM, and MAPMEM.COM from your
directories. The new versions of these programs are EXE files instead
of COM files.

Always be sure to make just one version of the TSR Utilities
accessible on your disk. Many of the utilities cooperate with one
another and require matched versions to work correctly.

See the source code for the programs for more detailed information
about changes.

Version 3.2  11/22/91
  All
    - the approach to identifying high memory blocks was generalized
      to allow the utilities to work with more memory managers
  MAPMEM
    - handle some DRDOS 6.0 segment numbering conventions
    - fix cosmetic indentation problem in raw extended memory summary
  RELEASE
    - reverse order in which memory blocks are released to work
      correctly with the 386MAX high memory manager
    - merge free blocks in high memory when possible (QEMM doesn't do
      this automatically)
    - don't restore parent segment if it's no longer valid (applies
      to QEMM LOADHI)
  RELNET
    - a change made in 3.1 caused RELNET to crash under DOS 3.3
    - reverse order in which memory blocks are released to work
      correctly with the 386MAX high memory manager
    - merge free blocks in high memory when possible (QEMM doesn't do
      this automatically)
    - don't restore parent segment if it's no longer valid (applies
      to QEMM LOADHI)
  WATCH
    - deal with odd vector addresses as trapped by DOS 5 MODE command

Version 3.1  11/4/91
  Documentation
    - clarified compatibility issues with various versions of 386MAX
      and QEMM386
  MAPMEM
    - EMS report wasn't showing last EMS block
    - there was a name reporting problem with TSR's that shrink their
      environment block to zero size but don't deallocate it (found
      with FluShot+)
    - was leaving interrupts 0, 3F, and others pointing to itself
      after halting
    - wouldn't show command line and hooked vectors for TSR's that
      overwrote the low portion of the PSP with data
    - wouldn't find a program (using /C) whose name was stored in
      lowercase in the environment (noticed with Windows 3.0).
  RELNET
    - needed to restore less of the DOS variables table. Restoring
      something in the previously restored region sometimes disabled
      high memory access after the release
    - added /I option to prevent shutting down IPX events and sockets
  RAMFREE
    - now supports >640K free RAM
    - now adds RAMFREE's environment block to free memory reported
  WATCH
    - lost control of int 21 when FluShot+ grabbed it
    - didn't save vector change when a program grabbed int 27
    - didn't update stubs when a program grabbing int 21 or 27 was
      released
    - ended up rewriting WATCH again to solve these compatibility
      problems. The memory consumed by WATCH shrank by 1700 bytes as a
      result!

Version 3.0 10/12/91
  Numerous changes to provide compatibility with MS-DOS 5.0 and
  programs loaded into high memory. See TSR30.DOC for details.

Version 2.9  5/4/89
  MAPMEM
    - fix problem when EMS is available but none is allocated
  DISABLE
    - fix problem when TSR to disable is last one loaded
    - disallow disable when patches would overlap (SK+)
    - add /O option to allow disable even for overlap (Periscope)
  RELEASE/RELNET
    - don't treat file marks as protected marks

Version 2.8  3/10/89
  add MARKNET/RELNET
  add DEVICE
  add extended memory reporting to MAPMEM
  add TSR detection capability to DISABLE
  treat file and net marks as protected in RELEASE
  add key stuffing routine to RELEASE
  remove 8259 revector routine from RELEASE (available in RELNET)

Version 2.7  3/4/89
  used for private testing of MARKNET/RELNET

Version 2.6  1/15/89
  fix problem in MARK/RELEASE when command processor is EXE file
  convert source to Turbo Pascal 5.0

Version 2.5  6/2/87
  version checks to avoid mixing different MARK/RELEASE
:
many intervening versions
:
Version 1.0  1/2/86
  initial version

For information about other versions, see the source files.


9. Copyright and License Information
---------------------------------------------------------------------
The TSR Utilities are Copyright (c) 1986,1991 by Kim Kokkonen. All
Rights Reserved.

Although these programs are copyrighted, you may distribute them
freely as long as you do not sell them or include them with other
software that you sell. The TSR Utilities may be sold by user's groups
and shareware distributors for a fee not to exceed $10. Otherwise, if
you wish to sell the TSR Utilities, alone or as part of another
software package, please contact us for a license agreement.

These programs are not shareware: we're not asking for a donation.
However, if you request that we send you a new version, we'll ask for
$20 to cover our time and costs. The disk you receive will include the
latest version of the TSR Utilities, including the complete source
code.

We upload new versions of the TSR Utilities to LIB 6 of the PCVENB
forum on CompuServe. The executable programs are stored in a file
called TSRCOM.ZIP, and the source code is stored in a file called
TSRSRC.ZIP. From CompuServe, the programs fan out to public bulletin
boards around the world.

TurboPower Software also maintains a small bulletin board system just
for the purpose of downloading our software. The BBS number is
719-260-9726. You'll find TSRCOM.EXE and TSRSRC.EXE in file area 2
(TurboPower Software Files). These are self-extracting archives. Our
BBS is a Wildcat! system; just follow the prompts to log in the first
time. Due to the transient nature of bulletin boards, we cannot
recommend other BBS's you should call to download the latest version.

The TSR Utilities were written by Kim Kokkonen of TurboPower Software,
with thanks to Neil Rubenking for the original idea behind MARK and
RELEASE. Special thanks also to Richard Wilson and Barry Simon at
Cal Tech for the idea that lead to FMARK, and for much useful
correspondence about the TSR Utilities. The TSR Utilities are written
in Turbo Pascal and assembly language.

You can reach Kim Kokkonen at:

     TurboPower Software
     P.O. Box 49009
     Colorado Springs, CO 80949-9009

     719-260-6641 (voice, Monday-Friday 9AM-5PM)
     719-260-7151 (fax)
     Compuserve: 76004,2611