Programmer 7500

home *** CD-ROM | disk | FTP | other *** search

/ Programmer 7500 / MAX_PROGRAMMERS.iso / PASCAL / TSRCOM31.ZIP / TSR.DOC < prev next >

Wrap

Text File | 1991-11-04 | 47.5 KB | 1,139 lines

TSR Utilities Version 3.1 Kim Kokkonen TurboPower Software 11/04/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. 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 under DOS 5, 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. The /Q option is useful when you are using MARK in an integrated system. Note that redirecting MARK's output wastes 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 (DOS 5). /? 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 won'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) under MS-DOS 5.0. It may be 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 DOS 5.0. Note, however, that recent versions of QEMM386 and 386MAX respect the DOS 5.0 upper memory architecture and thus the TSR Utilities will work correctly if you're using these versions of QEMM386 or 386MAX with DOS 5.0. In some cases it is necessary to put the one of the following statements in your CONFIG.SYS file: DOS=HIGH,UMB -or- DOS=UMB The following table provides compatibility details on recent versions that we've tested: Memory Manager Compatibility with TSR Utilities upper memory features -------------- ------------------------------------------------------ 386MAX 5.12 ok (don't put UMB in CONFIG.SYS) 386MAX 5.11 ok (don't put UMB in CONFIG.SYS) 386MAX 5.10 not compatible 386MAX 5.00 not compatible QEMM386 6.00 ok (requires UMB in CONFIG.SYS) QEMM386 5.11 not compatible If you have other memory managers, we'd like to hear your results. Try MAPMEM /U with and without DOS=UMB in your CONFIG.SYS. If you get a high memory report from MAPMEM, and if your memory manager is still able to load TSR's into high memory, then you can assume that the memory manager is compatible with TSR Utilities 3.0. Note that even if the table says "not compatible" you can still use the TSR Utilities 3.0 without upper memory support. 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. 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. 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. 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. Note that 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 under DOS 5.0. 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, under MS-DOS 5.0, 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 (DOS 5). /? 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 MS-DOS 5.0 upper memory blocks. You cannot disable a TSR loaded high without using this option. As with RELEASE and RELNET, you must generally have the statement DOS=HIGH,UMB in your CONFIG.SYS in order to use the DISABLE /U option. 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 /U disables 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.0, 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 MS-DOS 5.0, 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. 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 (DOS 5). /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. The TSR Utilities cannot access the high memory managed by DR DOS 6.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 keep just one version of the TSR Utilities 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.1 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 distributed 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