Table Of Contents

Index

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

    MARK
    TSR1
    MARK
    TSR2
    MARK
    TSR3

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

    RELEASE TSR2

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 TSR1
    TSR1
    MARK TSR2
    TSR2
    MARK !TSR3
    TSR3

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

    RELEASE !TSR3

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

    FMARK [d:][directory]filename

    FMARK C:\TEST\TEST.MRK

    RELEASE TEST.MRK
    RELEASE C:TEST.MRK

    RELEASE C:\TEST\TEST.MRK

Consider the following example:

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

TSR2 can be removed from memory by entering

    RELEASE C:\MARKS\TSR2.MRK

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

    RELEASE TSR1

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

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.

    SET RELEASE=/U/Q

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:

   RELEASE SK
   LOTUS
   MARK SK
   SK

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:

  batch1:
    RELEASE SK /S BATCH2

  batch2:
    LOTUS
    MARK SK
    SK

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

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.

Table Of Contents

Index