Category : Utilities for DOS and Windows Machines
Archive   : TSRWRK31.ZIP

Output of file : LOADTSRS.DOC contained in archive : TSRWRK31.ZIP

LoadTSRs Documentation

LoadTSRs is NOT a program. It is a SYSTEM. The LoadTSRs system
consists of three BAT files and an EXE assembly language program.
The TSRmenu.BAT (1st BAT file) invokes the MenuTSRs.EXE program
which creates the Load2TSR.BAT (2nd BAT file). Load2TSR.BAT does
the loading of TSRs selected from a MENU of TSRs displayed by the
MenuTSRs.EXE program. The last line of Load2TSR.BAT chains to a
KillLoad.BAT (3rd BAT file) which deletes the Load2TSR.BAT file.

The LoadTSRs system, as you receive it therefore, contains only
the TSRmenu.BAT and KillLoad.BAT files plus the MenuTSRs.EXE and
its source code. This LoadTSRs.DOC file may help you learn more
about operating your computer in the process of explaining this

Although the LoadTSRs system, like ShowTSRs, UnMark, ReMark etc
are provided for programmers, novices can be "programmers" in my
definition of the target audience. All that is necessary for you
to benefit from what I place in the public domain is willingness
to learn to program. The idea that "users" should be isolated
from the operating system or the means by which the CPU (central
processing unit) is instructed is a "dumb" one. It gives me the
same feeling in my lower regions to think that someone operating
a computer for me has been kept ignorant as it would to hear that
school bus drivers have been trained as passengers. If you don't
want to know anything about the operating system or are unwilling
to try your hand at programming, then erase these files now!

I'll assume that no one is reading simply because they did not
know how to erase a file... Lets review some BAT file concepts.

With Version 3.3 of MS-DOS, a BAT file can "call" another BAT
file. What does that mean? BAT files commonly have a line which
invokes a program. The line in TSRmenu.BAT which reads:
is an example. The operating system, when it encounters this
line, loads and executes the program. When the program ends -
(terminates), the operating system resumes in the BAT file right
after the "MenuTSRs" line with the program termination code in a
BAT variable known as "ERRORLEVEL". The BAT file then continues
with its next line.

It is as if the BAT file said, "Go To this program AND come back
with the result." Here, for example, is the TSRmenu.BAT file:
Echo Off

Notice the blank line at the end. This says, "done" and prevents
a double prompt caused by the BAT file processor going back for a
line which does not exist. But, let us concentrate on content...
The BAT file test for an ERRORLEVEL will be TRUE for a specified
or any higher level. Only when MenuTSRs exits with 0 ERRORLEVEL
will the jump over the %MrkDir%\Load2TSR NOT take place.

LoadTSRs.DOC page 1

MS-DOS versions before 3.3 do NOT provide for calling another BAT
file. If the Load2TSR.BAT file line is invoked, the Label:
will never be reached. It is as if the TSRmenu.BAT file had said
"Go To Load2TSR.BAT AND DON'T come back!" The operating system
BAT file processor only handles one BAT file at a time. When the
next BAT file is "chained", the processor starts all over again.
This is NOT bad. In fact, it is GOOD!... Suppose you desired to
swim 20 laps of a pool. Can you see the merrit in comming up for
air at the end of each lap. Starting over lets DOS update itself
providing the same refreshment as the swimmers breath of air.

APPLICATION: You are considering the hire of a consultant to
train your computer users. Ask the applicant to write your
AutoExec.BAT file and give a long list of preparation actions
required before the user receives control at the DOS prompt.
If the applicant produces a multi-page AutoExec.BAT file, then
write "unqualified" on the application. If the applicant's
AutoExec.BAT file is short and begins a series of "chained" BAT
files, with the secondary BAT files placed at logical points,
then hire the applicant.

My AutoExec.BAT contains only my virus protection system. If an
infection is found, it chains one way and if the system is Ok it
chains to a SetPaths.BAT which, in turn, chains to a StartUp.BAT
which has a number of alternatives. Let us suppose that the next
chain is LoadTSRs.BAT which contains:
Set TSRdir=C:\TSRs
Set MrkDir=G:
FMark %MrkDir%\Watch

The BAT file processor substitutes the Environment String which
was set to "G:" for the variable %MrkDir%. The FMark line would
be "FMark G:\Watch". Note that the backslash "\" is literal.

This might be a good time to use the MS-DOS "TYPE" command to see
the MenuTSRs.EXE HELP screen. Do this:
prompt >TYPE MenuTSRs.EXE
"You can't TYPE an .EXE file!", you say. Well, do it any how...

See how the sample LoadTSRs.BAT file sets the requirements for
the LoadTSRs system. Use ShowTSRs, after the sample LoadTSRs
BAT file. You will see that the operating system CONFIG.SYS,
DOS SHELL and DOS ENVIRONMENT are followed by FMark G:\Watch,
Watch and a 128 byte LoadTSR line. MenuTSRs is a TSR itself!
It "signals" that requirements have been met for loading TSRs
from a menu. The "LoadTSR" line shows 6 instead of 5 under the
files column because the Load2TSR.BAT file is counted.

Naturally, you will need to put your TSR.COM files in the TSRdir
directory and have a MrkDir directory for the FMarks and the
Load2TSR.BAT file. TSR.EXE files and TSRs NOT in the TSRdir or
on the menu can still be loaded without use of MenuTSRs.EXE; but,
it IS important that each be preceeded by an FMark. We prepare
for changes to the TSR configuration by using FMarks. UnMark can
be used to remove and TSRmenu can then re-load TSRs to meet your

LoadTSRs.DOC page 2

Recall the "comming up for air" analogy. Using BAT files to
UnMark or ReMark TSRs depends on the BAT file chaining process.
When the BAT file processor switches BAT files, it gives DOS an
opportunity to recover its breath between such operations. It
really is better, however, to UnMark or ReMark from the command
line... After all, You are the system driver - NOT a passenger!

Now for the bottom line on BAT files. The LoadTSRs system does
NOT use BAT files just so that I could talk about them in this
document. If MenuTSRs.EXE loaded the TSRs while it was running
they would be installed above it (leaving a hole in memory when
MenuTSRs terminated. If installation was done by the resident
MenuTSRs, it would require a large resident for all the code.
The use of BAT files allows DOS to do the installation. Each
set of TSRs loads in the memory just vacated by MenuTSRs when
the Load2TSR.BAT is chained on termination back to TSRmenu.

There are some interesting procedures in MenuTSRs.ASM which are
worth consideration. The GetDirs Proc NOT only reads the master
DOS environment but corrects it if either the TSRdir or MrkDir
directories contains an ending "\". If you have NOT preset the
variables, this PROCedure takes your input (insuring at least 2
bytes and NO trailing "\"), and puts it into the DOS ENVIRONMENT.
There is a hazard in this! Your DOS MASTER ENVIRONMENT may NOT
have sufficient space for the additions. To insure that it IS
big enough, you will want to have a CONFIG.SYS
or similar entry. My "E:1024" entry provides an environment size
of 1k. You may need less or may want more...

The IfPSPA PROCedure is used to test TSRfileNames from either the
residents found in memory or your input against the list of files
in your TSRdir directory. Notice the care used to make sure that
the STACK is back UP to the RETurn address whichever way the Proc
reaches its RETurn ending point.

The MakeBAT and EndBAT PROCedures demonstrate creating, writing
to and closing a file. MakeBAT is called before the decision as
to whether to install or update the resident MenuTSRs so that an
error will NOT occur as a result of NO Load2TSR.BAT file being
found on the initial call that installs MenuTSRs as a TSR.

Displaying a value as HEX or as DECIMAL ASCII is demonstrated
by the BP2PSPA PROCedure and the NBX2ASC PROCedure. These are
commonly required assembly language routines. You may use or
modify them for your own programs.

The accumulation of a table of MCBs with a WORD size value for
each MemoryControlBlock address, the Address of the Block which
it controls, the size of the block and flags is used in all the
programs of the TSRwrk series. This table demonstrates how DOS
keeps track of what is resident in its memory. The last MCB or
currently running program has a MemoryControlBlock identified
with a "Z" and all others begin with an "M". These paragraphs
(16 byte blocks of memory) are what DOS uses when you Install
TSRs or Release them.

Tom Gilbert's Heart & Mind
7127 Lafayette Avenue
Kansas City, KS 66109

End of file - LoadTSRs.DOC page 3