home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
ftp.update.uu.se
/
ftp.update.uu.se.2014.03.zip
/
ftp.update.uu.se
/
pub
/
rainbow
/
msdos
/
latrobe
/
e
/
envsiz.arc
/
ENVSIZE.DOC
< prev
Wrap
Text File
|
1986-05-15
|
40KB
|
1,255 lines
ENVSIZE
Environment size control and display
Documentation File
A shareware product provided by:
Charles P. Scott / Team Alpha
519 Garden Springs Dr.
Mt. Sterling, KY 40353
(C) Copyright Charles P. Scott / Team Alpha, 1986
All rights reserved
1
Limitations on use and distribution
This product is being distributed as shareware. This means that it
can and should be distributed by any user who possesses a legitimate,
unmodified copy and follows a few simple rules.
At Team Alpha there are other products in the works which I hope
will relieve some of the frustration of working with a PC. Needless to
say, those products are somewhat more time consuming to create then
ENVSIZE and will unfortunatly take some months yet. In the time untill
they are available the facilities which have been created along the
way could be getting some use by those who can use them. This gives
others a chance to benifit and provides some contact for me with the
users who will eventually be evaluating my other products. To this end
my requests are simply:
A. If you find this program and the information contained in the
documentation of some value to you then please send fill out
the registration form at the back of this document and send to:
Charles P. Scott / Team Alpha
519 Garden Springs Dr.
Mt. Sterling, KY 40353
Or through Compuserve ( ID: 76556,3335 )
{ Of course any small donations would be appreciated. }
B. You may not charge any fee for this software or for it's
distribution. This includes a "DISK FEE" or similar charge.
C. You may not distribute any modified copy of this software or
it's documentation as the results may somehow end up reflecting
on my products.
D. You may not copy or reproduce the documentation for any other
propose than as a reference for a single legitimate user.
E. You may not distribute this software or documentation as a part
of any comercial package or for corporate or institutional
purposes.
I'm realy not as bad as it seems from all this. If you have a use
for ENVSIZE which does not conform to the above restrictions, please
contact me at the above address or call (606) 498-0181 during business
hours.
Since the Shareware concept was first introduced it has been very
successful in distributing a wide variety of first class software and
rewarding the authors who participate. Please take the time to
distribute this software by passing it on in it's complete and
original form to other "Computerists" and bulletin board systems.
2
If you would please bear with me, I would like to explain a bit
about how this program came to be and why I chose this method of
distribution. It seems that I have been struggling with the
environment ever since installing the hard disk in my Deskpro and
needed to achieve some degree of automation and control over the large
number of programs and utilities. This all came to a crytical point
when I installed my EGA and extended memory card which, so to put it,
caught MS-DOS with it's pants down. The stop-gap patches I had made to
COMMAND.COM which got me this far down the path to ruin became
unreliable at best and a better solution was required. The technical
reasons for all this are described later in this document and should
prove to be enlightening for the more casual users. (You hard core
computerists already have bruises on your forehead) So to further the
cause I entered another interrupt level in my work and created
ENVSIZE.
Charles P. Scott / Team Alpha
3
Table of Contents
-----------------
1. Overview of Parameters and the Environment
a) Basic introduction to Parameters and the Environment
b) Primary and subsequent Command Processors
c) Location of the Environment(s) in memory
2. Problems with using the environment
3. Solving the problem with ENVSIZE
a) ENVSIZE command syntax
b) Environment status display
c) Adding space to the environment
d) Batch execution of ENVSIZE
4. Technical Description of ENVSIZE
5. Associated problems and bugs in DOS
a) Providing Environment space in a SHELL
b) Avoiding the batch Parameter evaluation bug
6. Registering with Team Alpha
4
1. Overview of Parameters and the Environment
a) Basic introduction to Parameters and the Environment
In PC-DOS and MS-DOS a Parameter is a string of characters
which has a name assigned to it and is stored in an area called
the Environment. The information so stored in the Environment
may be used by a batch process, DOS or may provide information
to certain programs. These strings may be created and listed
using the command "SET". An example of this is found below.
List all Parameters currently in the Environment.
C>set <- Typed by user
COMSPEC=C:\COMMAND.COM <- Response from DOS
PATH=c:\;c:\dos
Enter a new Parameter into the Environment.
C>set author=Chuck <- Enter new Parameter
C>set <- List Parameters in Environment
COMSPEC=C:\COMMAND.COM
PATH=c:\;c:\dos
AUTHOR=Chuck <- Parameter AUTHOR now listed
Delete a Parameter from the Environment.
C>set author= <- Delete AUTHOR parameter
C>set <- Author no longer in Environment
COMSPEC=C:\COMMAND.COM
PATH=c:\;c:\dos
The Primary Command Processor (COMMAND.COM) has access to the
Environment and is allowed to make permanent changes to it's
contents. In fact some Parameters are inserted or modified by
commands other than SET Such as PROMPT and PATH. One Parameter,
COMSPEC, is placed in the environment by the Primary Command
Processor when the system is booted. This parameter is used by
the command processor to locate itself on the disk when the
transient portion of COMMAND.COM is overwritten by a program and
needs to be replaced. PROMPT and PATH are accessed by their
corresponding commands as shown below.
5
C>prompt=? <- Set the prompt text
?set <- Notice that prompt is "?"
COMSPEC=C:\COMMAND.COM
PATH=c:\;c:\dos
PROMPT=? <- Prompt text stored here
?prompt <- Restore prompt to default
C>set <- PROMPT deleted from Environment
COMSPEC=C:\COMMAND.COM
PATH=c:\;c:\dos
Certainly all of the above is covered in most of the MS-DOS
manuals and associated books but there is actually more to know
about the environment and how to use it.
b) Primary and subsequent Command Processors
Before we can get into the problems with making extensive use
of the environment and the need for the ENVSIZE program, it is
necessary to understand where things are in memory and to some
extent how they are organized. First of all we must understand
that at any one time there may be multiple copies of the
Environment and the Command Processor.
When your PC is first turned on or is rebooted a sequence of
events occurs which culminates with running a file called
COMMAND.COM. This is the Command Processor. It displays a prompt
on the display and waits for a command from the user (or a batch
process). When a command is entered, the Command processor
evaluates that command and initiates a sequence of events to
perform the requested operation. This Command Processor, which
is loaded when the system is booted, is called the Primary
Command Processor and is located below any other programs in
memory (with the exception of installed drivers, IBMBIO and
IBMCOM).
The command SHELL in BASIC allows a user to seemingly re-enter
DOS and enter commands as if we had never run basic. In fact
what has happened is that BASIC requested that the program
COMMAND.COM (found by the Parameter COMSPEC) be run in the
available memory above BASIC. This results in a secondary copy
of the Command Processor which is not exactly like the original.
Sure it seems to work the same but the Environment Parameters
which can then be accessed with the SET command are a copy of
the originals associated with the Primary Command Processor. As
a result of all this any changes made to these Parameters will
not be seen when you finally return to the Primary Command
Processor. Also there is a difference in where this Environment
is located in relation to the current Command Processor which
restricts adding Parameters (I will explain how to avoid this
problem later). Since many copies of the Command Processor and
it's Environment may be in memory at one time, there can be a
variety of ways that operation may be different from the Primary
Command Processor.
6
A copy of the Environment and how to find it is also passed to
each program as it is loaded and run. This allows application
programs to read Parameters and modify them, although any
changes will only be seen in a subsequent program or SHELL run
from that program.
c) Location of the Environment(s) in memory
At this point I think it would be wise to show how these
things are located in memory and explain their limitations and
the reasons for them. The following two memory maps show where
the various components are located for just the Primary Command
Processor and then with another program running.
1) Primary Command Processor Only
************************************* 0k
* *
* INT vectors and System Info. *
* *
*************************************
* *
* IBMBIO, IBMDOS & Device Drivers *
* *
*************************************
* *
* Primary Command Processor *
* *
*************************************
* Primary Environment *
*************************************
* *
Free memory space
* *
************************************* End of RAM
Note: The Environment Follows the Command Processor.
7
2) Primary Command Processor and another program
************************************* 0k
* *
* INT vectors and System Info. *
* *
*************************************
* *
* IBMBIO, IBMDOS & Device Drivers *
* *
*************************************
* *
* Primary Command Processor *
* *
*************************************
* Primary Environment *
*************************************
* Program Environment *
*************************************
* *
* Program *
* *
*************************************
* *
Free memory space
* *
************************************* End of RAM
Note: The program and the Command Processor
Environments are boxed in and can't expand.
8
2. Problems with using the Environment
By looking at at the charts above it can be seen that when
only the Primary Command Processor is loaded, and there are no
other programs (including resident programs) in memory, the
highest occupied area of memory contains the Environment. This
means that the Environment has room to be expanded when the
space required for the Parameters being entered (via the set
command, PROMPT or PATH) exceeds the size of the environment. As
far as I know, all versions of MS/PC-DOS start with an
environment size of 10 paragraphs (160 bytes). A quick
calculation indicates that this is a fairly small space for even
modest use of the environment. Since there is some overhead in
the Environment, such as a null (0) between each Parameter and a
double null after the last one, this really amounts to about
five Parameters of thirty characters each, and that has to
include the Parameter names and an "=". Needless to say we will
generally require more space. Fortunately when no other programs
follow the Command Processor the Environment is free to expand
and will as required.
The real problem occurs when another program is loaded after
the Primary Command Processor. Looking at our second chart we
see that there is no longer room for expansion of the Command
Processor's Environment. Most PC users have in their software
arsenal at least one "resident" program and many users
automatically load at least one with their AUTOEXEC.BAT file.
For those people there has been no hope of using any more than a
very few Parameters. Even if you decide not to load resident
programs at boot-up, there is a limitation to how much may be
entered into the environment by the AUTOEXEC batch process. The
reason is that a small block of memory (between 4 and 6
paragraphs) is allocated for management of a batch process and
it is placed in the next available memory space, right smack at
the end of our 10 paragraph Environment. If you don't believe me
just try using a batch file to place a number of Parameters into
the Environment and you will see the limitations.
There seems to be only one conventional solution to this
problem. That is to manually enter, at the keyboard, all of the
Parameters required or enough Parameters to cause the
Environment to expand to the required size. Use of "dummy"
parameters (ie: set a=xxxxxxxxxxxxxxx) is about the best way of
doing it. Then when the size is where you want it you will have
to remove the dummy Parameters with the SET command to free that
space up and then run a batch file to continue your start-up
sequence. Fortunately the environment will not then contract on
you. But what a royal pain!
When a program or another copy of the Command Processor is
loaded by DOS, a copy of the current Environment is placed in
the first available memory and the program is loaded in the
following space. The size of the Environment "copy" is only
enough to include those Parameters in existence at that time.
Because of this the new Environment is boxed in and has no
chance of being expanded. When the loaded program is another
copy of the Command Processor, use of the SET command to add
9
Parameters will, for the most part, be futile.
Fortunately there is a hero in our story. In the sections to
follow I will explain how to use the ENVSIZE program to expand
the size of the Environment for the Primary Command Processor
and how to secure space in other copies of the environment.
10
3. Solving the problem with ENVSIZE
The ENVSIZE program has been created to help us solve the
problems associated with what I consider to be reasonable use of
the environment. It does this by expanding the Environment of
the Primary Command Processor and reporting on the status of the
current Environment.
a) ENVSIZE command syntax
There are two forms of command syntax for the ENVSIZE
program. One to report on the status of the current
Environment and the other to expand the Primary Environment
size. If at any time you would like to review these commands
on line simply type "ENVSIZE" as shown below.
C>envsize
Usage: envsize <paragraphs> ;add number of paragraphs
envsize ? ;report size in paragraphs
Note: there will also be a copyright notice and other
information displayed.
b) Environment Status Display
ENVSIZE can provide information on the current Environment by
simply entering "ENVSIZE ?".
C>envsize ?
Current environment statistics:
Size in paragraphs.............(DEC)...... 10
Size in paragraphs.............(HEX)...... 000A
Size in bytes..................(DEC)...... 160
Location of environment........(Segment).. 0F47
Location of command processor..(Segment).. 0E86
Current command processor is primary...... YES
The size in paragraphs is reported in both Decimal and
Hexadecimal for convenience. The locations of the Environment
and the Command Processor make it easy to examine the
environment with DEBUG and help to understand what exactly is
happening. In the above example, for instance, the Environment
is located higher in memory than the Command Processor. This is
because the current Command Processor is the Primary copy.
Therefore the above display would indicate that the Environment
may yet be expanded (provided no resident programs exist). If
the "ENVSIZE ?" command said that it was not the Primary Command
Processor then the Environment would be located below the
Command Processor and could not be expanded.
11
c) Adding space to the Environment
To add space to the Environment associated with the Primary
Command Processor simply enter "ENVSIZE n", where "n" is the
number of paragraphs you would like to add to the current size
(the present maximum is 256).
C>envsize 10
Current environment statistics:
Size in paragraphs.............(DEC)...... 20
Size in paragraphs.............(HEX)...... 0014
Size in bytes..................(DEC)...... 320
Location of environment........(Segment).. 0F47
Location of command processor..(Segment).. 0E86
Current command processor is primary...... YES
The statistics display which follows the command indicates the
status after the space has been added. If for any reason it is
not possible to allocate all of the desired space, only that
available will be allocated and the status display will reflect
what was actually obtained.
There is a practical limit to the size of the environment
above which the system will not be able to use. That size is
2048 paragraphs or 32K. I should hope that would suffice! Any
attempt to exceed that limit will result in only 2048 total
paragraphs for the environment and a message being displayed.
Additionally there is a limit imposed by the current version
of ENVSIZE which you now have. Unfortunatly the method I used to
perform this computerized "slight of hand" requires it to have
enough free space contained in the program to place it's code
above any action which would otherwise tend to corrupt it. To
provide a version which would allow you to expand the
Environment to it's full 32k in one shot would therefore require
a program about 40K in size. This not only takes up disk space
but makes it time consuming to transfer by modem. I promise that
at some point in the future I will rewrite the code so that this
will not be a problem. For the time, however, if you require
more than 4k additional Environment space you will have to
repeat execution of ENVSIZE.
If any attempt is made to expand any environment other than
the primary copy an informational message will be displayed and
no action will be taken. For information on how to provide space
in other copies of the Environment, read "Associated problems
and bugs".
d) Batch execution of ENVSIZE
Due to the way ENVSIZE modifies the Environment size certain
restrictions are placed on it's use within a batch file. To
better understand why these restrictions exist read the
"Technical Description" section which follows. Suffice it to say
that I violated some basic rules of DOS which would allow
corruption of the batch process should you not follow a few
12
rules. In essence the safest thing to do in a batch file after
the ENVSIZE command is to chain (transfer execution) to another
batch file or end the batch process.
Thefollowing is an example of the safest way to use the
ENVSIZE command in a batch file and is how my system boots up.
File name: AUTOEXEC.BAT
envsize 100
autoexe2
The AUTOEXE2 command executes a batch file called AUTOEXE2.BAT
which continues by loading certain resident programs, setting
the PATH and PROMPT parameters as well as those Parameters
required by other programs I use and starting the DOS shell I
use for hard disk management. When the whole process is complete
I have everything set-up the way I like it, with a 1760 byte
Environment. (the original 10 paragraphs + 100 new paragraphs *
16 bytes/paragraph = 1760)
The rules you should follow when using ENVSIZE in a batch file
are as follows:
1) Never follow the ENVSIZE command with a command
which would add a Parameter to the Environment,
such as the SET, PROMPT or PATH commands.
2) Do not follow the ENVSIZE command with a command
which would result in the execution of another
program. You are welcome to try this, but I don't
guarantee the results.
3) Only follow the ENVSIZE command with either
"INTERNAL" commands (those which can be executed
entirely by the Command Processor, ie: DIR,
CHDIR, etc.) or the name of another batch file.
13
4. Technical Description of ENVSIZE
Simply put ENVSIZE reallocates the memory block associated
with the Primary Environment, using DOS function 4A, to be of
the desired size. As we know however, any program loaded after
the Primary Command Processor will cause allocation of memory at
the end of the Primary Environment preventing it from being
expanded. This is therefore true with ENVSIZE. What I have done
is to have ENVSIZE deallocate the memory associated with itself
including it's Environment before reallocating the Environment
space. This may seem to be a bit dangerous because it leaves the
memory in which ENVSIZE is executing unallocated. But actually
there is little which can cause trouble at that time unless
there might happen to be a real strange resident program or
driver running. When ENVSIZE then terminates, the operating
system is left only to deallocate the memory which has already
been deallocated, and there seems to be no trouble with that.
Therefore the ENVSIZE scheme works.
As usual there are some other problems to contend with and
they are related to batch processes and Memory Allocation Blocks
(MAB's). Both are somewhat related. When a batch process is used
to call the ENVSIZE program, a small (4 to 6 paragraphs) block
of memory is allocated for batch process housekeeping and it is
located in the first available space past the Environment. This
would prevent expansion of the Environment during batch
processes and would severely limit the usefulness of this
program. To circumvent this problem ENVSIZE simply deallocates
that block of memory leaving it available for Environment space.
The problem with this is that any unwanted modification of this
area of memory would result in very unpredictable behavior. So
this won't happen, the ENVSIZE program will not allow less than
15 paragraphs to be added, thus preventing an MAB entry from
landing on top of that memory. This is also why there are some
restrictions on the use of ENVSIZE in a batch file. For example,
if enough new Parameters were then added, the area of memory
used by the batch process would eventually be overwritten since
it is now part of the Environment. When the batch process
eventually terminates, or a new batch file is chained, this area
will not be used any more except for Parameters. Problem solved.
The other part of this problem is with the PSP and code for
ENVSIZE itself. Since violation of that space could prove to be
fatal it is protected by placing the start of the program code
4k up in the code segment. Along with the batch process space,
the PSP is protected by the minimum number of paragraphs which
ENVSIZE will allow to be added and the 256 paragraph maximum
limit protects the code. Which is why I have decided to
distribute this version with a 256 paragraph limit per
execution. The size of ENVSIZE.COM is now about 10 Kbytes rather
than the some 40 K which would be required to allow the full
2048 paragraphs in one shot. The compromise seems to be
reasonable. I hope at some later time to have a version which
relocates itself and would avoid that limitation.
I realy don't want to wear out my welcome but there is one
14
more trivial thing. When a memory block is allocated it has
placed in it the segment number of the parent program. So when
ENVSIZE reallocates the Environment it, what you might say,
adopts it. If that memory block was not un-adopted before
ENVSIZE terminates it would be in danger of being lost
(deallocated). To prevent this the parent segment number is
returned to that of the Command Processor before termination.
15
5. Associated problems and bugs in DOS
Just as a point of information and to facilitate better use of
the Environment let me explain a little about the problems of
using Parameters in MS-DOS. As I explained above, there is a way
to provide space for Parameters in a copy of the Environment
associated with a subsequent Command Processor (SHELL). I will
describe this method and explain how to avoid a bug in the way
the batch processor evaluates parameters.
a) Providing Environment space in a SHELL
Normally when a copy of the Environment is provided to a
subsequent Command Processor it is provided with only as
much space as is required by the Parameters it contains.
Since it is not possible to expand that copy of the
Environment, it must have been passed with DUMMY Parameters
which are there simply to take up space. If in your
AUTOEXEC.BAT file you use SET to include a number of these
DUMMY Parameters you will always be able to delete them with
the SET command and enter real Parameters. The following is
a real example.
Primary Environment before adding DUMMY
C>set
COMSPEC=C:\COMMAND.COM
PATH=c:\;c:\dos
Add the DUMMY Parameter
C>set filla=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Environment with DUMMY Parameter
C>set
COMSPEC=C:\COMMAND.COM
PATH=c:\;c:\dos
FILLA=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Invoke a SHELL
C>command
The COMPAQ Personal Computer MS-DOS
Version 3.10
(C) Copyright COMPAQ Computer Corp. 1982,83,84,85
(C) Copyright Microsoft Corp. 1981,82,83,84,85
16
Try to insert a Parameter
C>set author=Charles P. Scott
Out of environment space <- No space
Remove the DUMMY Parameter
C>set fillA=
C>set author=Charles P. Scott
C>set
COMSPEC=C:\COMMAND.COM
PATH=c:\;c:\dos
AUTHOR=Charles P. Scott <- Took it this time
I suppose you might ask why all this trouble. The answer
lies with two particular situations. When the SHELL command
is used from BASIC or a DOS SHELL is invoked by an
application program the user is restricted by Environment
limitations, especially with respect to batch file
branching. Also there is a way to use a subsequent copy of
the Command Processor COMMAND.COM to simulate subroutines in
a batch file. But that is another subject which is addressed
in several of the better MD-DOS books.
b) Avoiding the batch Parameter evaluation bug
Just in case you have not already run across the Parameter
evaluation bug in MS-DOS I will describe it here and explain
how to avoid it. The problem occurs when an IF statement is
used to evaluate a parameter as shown here.
IF %AUTHOR%==Charles P. Scott goto SKIP
.
.
:SKIP
.
When the Parameter "AUTHOR" exists in the Environment the
string "%AUTHOR%" is substituted with that Parameter's
value. If It does not exist it is evaluated as "AUTHOR%",
without the leading "%". Actually this is a benefit because
it allows you to test for a non-existent Parameter as in the
statement below.
IF %AUTHOR%==AUTHOR% goto NOTFOUND
17
Well at least that is true up to my Compaq DOS version 3.1
where they have apparently tried to save face and ruined it
for us. Now the nonexistent Parameter is evaluated to a null
string (no characters) and will always produce a syntax
error.
IF ==Charles P. Scott goto SKIP
That is how the line would try to execute in that version
of DOS and would cause an error. With such a "correction" it
becomes impossible to branch on a nonexistent Parameter
without first eliminating all other possibilities!
I hope that you have found this information of some value and
not too much of a bore. Please don't hesitate to contact me if
you have any comments on the above material or the program
itself. Certainly if you find there to be some problems, let me
know so that I can help you work them out or correct for them in
future versions.
18
6. Registration with Team Alpha
Once you have evaluated this program fill out the following form
and send it to:
Charles P. Scott / Team Alpha
519 Garden Springs Dr.
Mt. Sterling, KY 40353
Or via Compuserve: 76556,3335
USER NAME____________________________________________________
COMPANY ____________________________________________________
ADDRESS ____________________________________________________
____________________________________________________
____________________________________________________
PHONE # (optional) __________________________________________
Equipment type, configuration and operating system
___________________________________________________________
___________________________________________________________
Estimate of your computer skill level
___________________________________________________________
How you obtained a copy of ENVSIZE
___________________________________________________________
Comments and suggested enhancements
___________________________________________________________
___________________________________________________________
___________________________________________________________
19
