home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Phoenix CD 2.0
/
Phoenix_CD.cdr
/
24b
/
getenvr.zip
/
GETENVR.DOC
< prev
Wrap
Text File
|
1986-01-19
|
4KB
|
100 lines
GETENVR.DOC
INTRODUCTION
Starting with DOS 2.0, a series of strings known as the command
processor's environment is available for use by all DOS commands and
programs. DOS did not provided a mechanism for programs to directly
access the command processor's environment. Programs can only access a
copy of this environment. The assembly language program, GETENVR, shows
how to access the command processor's environment.
BACKGROUND
The DOS manual under the SET command suggests entering keywords and
parameters, while not meaningful to DOS, could be found and interpreted by
programs. This is a great idea but DOS only allows access through the
"SET" command while in the command mode. This means that an individual
must enter these keywords and parameters manually.
PASSED ENVIRONMENT
When DOS loads a program, it also makes a copy of its environment and
leaves the segment address to this copy at offset 2C hex (H) in the
Program Segment Prefix (PSP). If a program changes, modifies or adds to
this copy of the environment, all is lost when the program terminates.
None of this information is passed back to DOS.
ACCESSING COMMAND PROCESSOR'S ENVIRONMENT
The procedure GET_ENV is the heart of the program, GETENVR. It determines
the segment address of the active command processor's environment. Once
this address is known, any program can easily access this master
environment. The program GETENVR illustrates this by displaying all the
strings in the master environment on the screen along with its address.
USING COMMAND PROCESSOR'S ENVIRONMENT
Now knowing the location of the master environment, new keywords and
parameters can be added. When being added, each string must be terminated
with a null byte (0H), and the last string in the environment must be
terminated by two null bytes.
The major limitation in using the environment is its limited space. The
original size is only 127 bytes. The only way to expand this with DOS 2.X
is to use the SET command to introduce a very long string which the
application program can delete later. This will only work if memory
resident programs, like Bourland's SideKick (c), has been loaded. With
DOS 3.10, there is a round about way to increase the environment using a
combination of documented and undocumented features of the shell command
in the config.sys file. The format is:
SHELL=C:\COMMAND.COM C:\COMMAND.COM /P /E:##
Replace ## with the number of paragraphs (16 bytes) desired for the
environment length. The break down of this is:
- The first "C:\COMMAND.COM" is the location from where the
command processor will be initially loaded.
- The second "C:\COMMAND.COM" is the location from where the
transient portion of the command processor will be loaded.
- "/P" makes the second "C:\COMMAND.COM" the permanent command
processor.
- "/E:##" sets the environment size in paragraphs.
This method of expanding the master environment in DOS 3.1 has not been
tested by the author.
MEMORY RESIDENT PROGRAMS
Memory resident programs can also use this capability. The copy of the
environment that is passed to these programs is not updated when changes
occur in the command processor's environment. Thus with the GET_ENV
procedure, memory resident programs could then access the master
environment and be able to adept to a changing environment.
PROGRAM DETAILS
The algorthm used for determining the segment address of the command
processor's environment is explained in detail in the .ASM file
documentation.
USER RESPONSIBILITIES
Since this program is released into the public domain, no restrictions are
placed upon its use except that GETENVR.DOC, GETENVR.ASM and GETENVR.COM
must be distributed free of cost and only the cost of the media can be
charged.
The author encourages comments. Please leave comments, suggestions, or
ideas in a message on Andy Smith's RBBS (301)-956-3396.
DISCLAIMER OF WARRANTIES AND LIMITATION OF LIABILITIES
The author has taken due care in writing this program, and the program is
supplied as is. The author makes no expressed or inmplied warranty of any
kind with regard to this program. In no event shall the author be liable
for incidental or conseqential damages in connection with or arising out
of the use of this program.
19 Jan 85 Raymond Moon