Jason Aller Floppy Collection

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

/ Jason Aller Floppy Collection / 267.img / RESIDNTC.ZIP / TSRUTIL.ZIP / TSR.DOC < prev next >

Wrap

Text File | 1989-05-05 | 35.5 KB | 797 lines

TSR Utilities Version 2.9 Kim Kokkonen TurboPower Software 5/4/89 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 programs 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. The documentation for version 2.8 has been revised substantially. If you're familiar with previous versions of the TSR Utilities, the most important change in v2.8 is the addition of MARKNET and RELNET. These new programs allow marking and releasing the Novell NetWare shell, as well as other "problem TSR's" that could not be released successfully in previous versions. 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. First, 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 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 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 RELEASE treats marks placed with FMARK just like protected marks. That is, they can be released only by explicitly naming them. (This is a change in behavior from versions of RELEASE prior to 2.8. The change is especially important when net marks, described below, are also in use.) Consider the following example: MARK 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 is treated like a protected mark. TSR2 can be removed from memory by entering RELEASE C:\MARKS\TSR2.MRK RELEASE deletes the mark file when it has finished. 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. /S chars stuff string (<16 chars) into keyboard buffer on exit. /? 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. /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. 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. MARK and RELEASE are capable of removing many, but not all, TSR's from memory. The TSR's that cannot be released fall into two categories: those that cannot be released without specific internal knowledge of the TSR, and those that can be released by storing additional general information about the system. The most common examples of TSR's that we can't be released without internal knowledge 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. Other TSR's modify well-defined areas of DOS memory that MARK and FMARK simply don't record. Examples of such TSR's include the Novell NetWare workstation shell and certain DOS utilities like MODE and SHARE. To deal with these programs we've written the MARKNET and RELNET utilities, described in the next section, which store just about every imaginable DOS data area, including some that are undocumented by MicroSoft. If you have trouble removing a particular TSR with MARK/RELEASE, try using MARKNET/RELNET instead. WARNING: you should not use either RELEASE or RELNET to try to release most disk caching programs. If you do so, part of the information that should be stored on disk will never make it, 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. WARNING: you cannot release the DOS 3.3 FASTOPEN or APPEND TSR's. These TSR's patch internal DOS data areas that cannot be reliably located by even MARKNET and RELNET. 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. Because MARKNET stores so much information about the system, it writes it to a disk file in order to reduce its own memory usage. Command line syntax for MARKNET and RELNET is: MARKNET [d:][directory]filename 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, 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, and other implementation details of DOS. 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. 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 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 RELNET has options to control how much of the system state it restores. Several of the options match those of RELEASE; new ones are needed because of the additional information that MARKNET stores. RELNET accepts the following options: /C do NOT restore the communications ports. /E do NOT access EMS memory. /K release memory, but keep the mark in place. /P do NOT restore DOS environment. /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. /V verbose: show each step of the restore. /? write help screen. None of these options is required in order to release the NetWare workstation shell. /C keeps 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. (We haven't tested MARKNET and RELNET on a PS/2 model 50z. Use caution if you have such a system.) 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. /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. /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. 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. /V activates additional status reporting during the release and may provide useful information in cases when RELNET isn't working. The following is a simplified 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 The items in uppercase, at least, 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 WATCH and DISABLE ------------------------------------------------------------------------------ WATCH.COM is a 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 the first TSR in your AUTOEXEC.BAT file. WATCH uses about 4000 bytes of memory when it is installed. Most of this memory holds various information about the TSR's installed in the system -- it includes two copies 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. 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. In order to use DISABLE, you must install WATCH.COM as the first memory resident program in your system. 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 "owner" column. If the owner 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. /? write a help screen. If no option is specified, DISABLE will disable the named TSR. Examples of usage: DISABLE SK disables SideKick DISABLE SK /A reenables SideKick DISABLE SK /C checks for the presence of SideKick DISABLE $2F2E disables the TSR at address 2F2E (hex) 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. WARNING: you cannot use DISABLE to deactivate SideKick Plus, whose swapping technique is incompatible with DISABLE. 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: PSP blks bytes owner command line chained vectors ----- ---- ----- -------- ------------------- ------------------------------ 0008 1 34240 config 1228 2 3536 command 1315 2 3888 WATCH TSR WATCHER 16 21 27 140A 2 22128 CED N/A 1B 21 64 1973 1 144 N/A C:\MARK\PS.MRK 197D 2 736 PSKEY S3 09 15 19AD 2 68400 PS /B:0 /E:1 /R:0 /... 01 03 06 0D 2A62 2 1504 MARK test 00 3F 2AC2 2 10384 EATMEM 10 2D4D 2 469808 free block bytes (Expanded Memory) ----- ------ 1 1048576 free 1048576 total 2097152 (Extended Memory) total 379240 "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. "Blks" 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. "Bytes" is the number of bytes of memory, specified in decimal, allocated to the program. The "owner" 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 (as shown on the fifth row of the report) or that the system is running DOS 2.x, where the owner names are simply not available. "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 with 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. The expanded memory report shows each allocated block of expanded memory, as well as the free and total EMS space. When extended memory is available, MAPMEM shows just the total amount available. The extended memory report is not highly reliable because of the lack of a standardized method for allocating extended memory space. Some applications that use extended memory allocate the space by making it appear that the memory is no longer in the system. MAPMEM shows the various types of marks so that you can examine them prior to a releasing them. As shown in the example, MAPMEM reports a call to MARK with the owner name "MARK", and the mark name (if any) in the command line area. The result of a call to FMARK or MARKNET will show "N/A" in the owner column (due to the minimal memory kept by an FMARK), and the name of the mark file in the command line area. MAPMEM offers the following command line options: /V verbose report. /? write a help screen. The verbose report 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. When it is non-zero, the maximum number of files opened by the rest of the programs (including the foreground application) is reduced accordingly. 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 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. Don't expect the sum of the DEVICE bytes to match the bytes reported by MAPMEM in the row labeled 'config'. MAPMEM's report shows what DOS thinks has been allocated, but that number isn't complete since some of the memory was used before DOS was truly loaded. However, you should find that the sum of the DEVICE bytes, plus all of MAPMEM's memory excluding the 'config' row, equals the total normal RAM in the system. 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. 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 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. 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 are EXE files instead of COM files. See the source code for the programs for more detailed information about changes. 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 limited 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 Version 1.0 1/2/86 initial version For information about other versions, see the source files. Copyright and License Information ------------------------------------------------------------------------------ The TSR Utilities are copyright (c) 1986,1987,1989 by Kim Kokkonen. All Rights Reserved. These programs are copyrighted, but license is hereby granted to distribute them for personal, non-commercial use. You may use them yourself, give them to your friends or co-workers, or distribute them for a cost-based fee ($10 or less) as part of a user's group or bulletin board service. If you wish to distribute these programs as part of a commercial package, please contact us for a license agreement. These programs 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 will include the latest version of the TSR Utilities, including the complete source code. The first (and only) place that we upload new versions of the TSR Utilities is on CompuServe, the BPROGA forum, in the latest Turbo Pascal library, which at this time is LIB 2. The executable programs are stored in a file called TSRCOM.ARC, and the source code is stored in a file called TSRSRC.ARC. From CompuServe, the programs fan out to public domain bulletin boards around the world. Unfortunately, due to the transient nature of bulletin boards, we cannot recommend where besides CompuServe you should call to download the latest version. The TSR Utilities were written by Kim Kokkonen, with thanks to Neil Rubenking for the original idea behind MARK and RELEASE. Special thanks to Richard Wilson and Barry Simon at CalTech for the idea that lead to FMARK, and for much useful correspondence about the TSR Utilities. You can reach Kim Kokkonen at: TurboPower Software P.O. Box 66747 Scotts Valley, CA 95066-0747 408-438-8608 (voice only, Monday-Friday 9AM-5PM) Compuserve: 72457,2131