Prev Next Home Home Table Of Contents Index


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. Be aware that any data in the TSR's that are being "released" will be lost if it has not been saved to disk.

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:


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:


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


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 are 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 !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


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 which RELEASE uses to 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


then the following calls to RELEASE would generate an error,


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


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:


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 deletes the mark file when it has finished.

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


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.
    /H         work with upper memory if available.
    /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         work with upper memory, but halt if none found.
    /?         write this help screen.

You can also put the string RELEASE=options in the DOS environment. For example, if you type


at the DOS command line, RELEASE will use the /U and /Q options as the defaults thereafter.

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.

/H is like /U (see below), but will continue even if no upper memory blocks are found.

/U will cause RELEASE to halt if no upper memory blocks are found. With /H you can write a batch file that works on all machines whether or not they have upper memory blocks.

/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:


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. Suffice it 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:



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:


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 notes: 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.

Prev Next Home Home Table Of Contents Index