Simtel MSDOS 1992 June/SIMTEL_0692.cdr/msdos/sysutl/tryst.arc/TRYST4.DOS

Text File | 1988-04-01 | 16.5 KB | 322 lines

                              TRYST DOS #4

     In the last article, the parts of DOS were covered.  This time,
CONFIG.SYS and AUTOEXEC.BAT will be discussed.

CONFIG.SYS

     In TRYST3.DOS, the IBMBIO.COM portion of PC-DOS was explained.
Since IBMBIO.COM is the part of DOS which controls the hardware, it
makes sense that this is the portion of DOS which looks for, and
executes CONFIG.SYS, since that file allows the user to customize
their system and include any instructions for operating any hardware
devices unknown to DOS.

     Essententially, CONFIG.SYS is a text file, ("text" meaning that
the user can read the file).  In this file, the user enters commands
which optimize their hardware or which contain instructions on how DOS
is to handle unknown devices such as a mouse or a hard disk with a
hard disk controller which DOS does not recognize.

     Users who have IBM PC-1 systems and have not upgraded the ROMs
will recognize this hard disk problem.  The ROMs in the original PCs
do not know about hard disks and they do not search through the PC for
other ROMs.  In newer machines, the PC's ROM searches certain
locations for other ROMs, and these "foreign" ROMs contain the
instructions used by the system to control the new hardware.  On a
hard disk controller board, there is a ROM which tells the system how
to access the hard disk.  Since the original PC's ROM does not search
for other ROMs, it has no way of knowing that a hard disk, or any
other similar hardware, is installed.  Therefore, on a PC-1 system,
you must either replace the ROM so that it will look for other ROMs,
or you must boot up on a floppy with a CONFIG.SYS file containing the
instructions for operating any hard disk you may have installed.

     So, the CONFIG.SYS file is used by DOS to operate any hardware
which DOS' IBMBIO.COM does not have explicit instructions for.  During
the booting process, IBM's ROM BIOS makes a trip around the system and
looks for other ROMs.  When it finds foreign ROMs, it allows them to
take control to check out the new devices and to incorporate their
controlling instructions into the working BIOS.  When all the ROMs are
done, IBM's IBMBIO.COM is executed to make any last minute changes to
the ROM BIOS, and to add any new code.  On a hard disk system, the
hard disk controller's ROM contains access instructions, and since the
hard disk is probably where your operating system software and your
CONFIG.SYS file are located, it makes sense that the IBM ROM looks for
and executes this ROM before attempting to continue the booting
process.  If the computer does not have the instructions for spinning
the hard disk and moving the read/write heads, how is it going to read
IBMBIO.COM, IBMDOS.COM and your CONFIG.SYS files?

     At any rate, when all the ROMs have been located and executed,
portions of their code remain in memory and become "part" of the BIOS.
Then IBMBIO.COM is read off the hard disk and in its turn, it looks
for the CONFIG.SYS file.  Since THE IBMBIO.COM file is not very big
and not very bright, CONFIG.SYS must be in the root so that it can be
found and executed.  After all, even if you set up your AUTOEXEC.BAT
file to include the "PATH" command to specify the directories on your
hard disk where you keep your programs, the AUTOEXEC.BAT file has
not been executed at this point, so the only location DOS will search
is the root.

     After IBMBIO.COM locates the CONFIG.SYS file, it loads any device
drivers listed in this file and they become further extensions to the
BIOS.  A device driver is simply instructions for handling other
devices and the data going to or from the device.  Device drivers are
files which have a .SYS, (or .BIN), extension on them.  Some samples
are:  MOUSE.SYS to operate a mouse, VDISK.SYS to take a portion of RAM
and set it up to run like a disk, and ANSI.SYS which allows the user
to control the display of information on the monitor.  All these
files must conform to standards set out by IBM on how a device driver
should be written, and since they are in machine language, the user
can not display their contents.

     If you are installing a mouse, for example, there is probably a
diskette with a MOUSE.SYS or some other .SYS file on it.  To set it up
you would use an editor which can produce a plain ASCII file, such as
WORDSTAR in the non-document mode, IBM's EDLIN editor, or Microsoft
WORD.  You just need one line:  DEVICE=MOUSE.SYS.  Save the file as
CONFIG.SYS and then reboot.  You must reboot to have this go "into
effect" since only on booting are device drivers installed with the
BIOS.

     You can have as many device drivers in your CONFIG.SYS file as
you need, using one "DEVICE=" line for each one.  A sample CONFIG.SYS
file could be:

DEVICE=C:\MOUSE\MSMOUSE.SYS
DEVICE=C:\DOS\VDISK.SYS 128 512 /E
DEVICE=C:\DOS\ANSI.SYS

     As you can see, if the .SYS file is in a subdirectory, such as
MSMOUSE.SYS being in the \MOUSE directory, you MUST specify the
directory as well.  The AUTOEXEC.BAT file has not been executed yet
so there are no search paths specified.

     The VDISK.SYS and ANSI.SYS files come on the DOS diskette.
VDISK.SYS is a nice utility which lets you set aside part of your RAM
to emulate a disk.  For example, if you have an AT, you could set
aside the extended memory above 640K with the /E switch and make a
virtual drive of 512Kb (assuming you have that much memory above
640Kb).  Then, you could copy files to the RAM drive by simply copying
to the D:  drive (assuming you have a C: hard disk already).
VDISK.SYS uses the next available drive designation, so if you have A:
& B:  floppies and a C:  hard disk, the virtual drive will be D:.  On
a system with just A:  and B:  floppies, the virtual drive with be C:.

     One thing you want to remember when you set up a virtual drive,
it is wiped out everytime you turn the computer off, so you must
remember to copy files back into your hard disk or floppy before
turning it off.  If you think you are likely to forget this, or are
afraid of power glitches, you could just copy your application program
files to the virtual drive, then it doesn't matter.  Keep your data on
the hard disk or floppy.  For example, if running DBASE, you could put
all the DBASE files (DBASE.EXE, DBASE.OVL, ASSIST.EXE, etc.) on the D:
virtual drive and just leave your database on the C:  drive.  You
would then access your data by including the drive designation with
the filename, such as C:MYDATA and C:MYINDEX.  Copying the DBASE files
into the D:  drive could be accomplished when you boot up by including
the "COPY DBASE.* D:" command in your AUTOEXEC.BAT.  You would not
have to copy the things from your virtual drive back to your hard disk
when done, since you still have the copy of the program on the hard
disk.

     ANSI.SYS is often required by software which wishes to position
the cursor on the screen by using escape sequences.  It is easier to
do this than to use the video software interrupt provided by the BIOS,
since many other kinds of computers use the same or similiar escape
sequences to control the location of the cursor.  Some games require
ANSI.SYS, and some software which allows the user to set up the screen
with different colors also use ANSI.SYS.

     In addition to adding new devices to your PC, CONFIG.SYS files
also have commands to "tweak" the best performance out of devices DOS
already knows about.  Some of the commands available include:
BUFFERS, FCBS, FILES, and LASTDRIVE.  A few software packages actually
insist that you use some of these commands in order to run their
application.  An example of this is DBASE, where you must increase the
default number of files which can be opened at one time or you will
not be able to use several indexes with your data base file.

     BUFFERS:  The BUFFERS command allows you to increase the number
of disk buffers allocated in memory when DOS is started.  This is a
tricky operation, too few buffers means hard disk access will be slow,
and too many will chew up your memory.  A buffer is an area used by
DOS to store data being read from a disk.  DOS tries to anticipate
what the user is going to be doing and be ready for it by reading
ahead.  When you ask for a record in a data base, DOS will read that
record and then the next couple of records, hoping that if you
continue working, you will request the record following the one you
are working on and it will not have to access the hard disk.

     But, each buffer increased the size of DOS by 528 bytes, so if
you go crazy and specify 99 buffers, you could find that you don't
have enough memory left to run your programs!  For most people, if you
are running a database, you will probably find that something between
10 and 20 will suit you.  To specify buffer size, you would enter the
following line in your CONFIG.SYS file.

BUFFERS=15

     On systems with hard disk, you will need a minimum of 3 buffers.
The default value for a PC is 2 and for an AT it is 3 buffers.

     FILES:  FILES allows you to specify how many file handles can be
opened concurrently.  The default value is 8.  This is the "newer"
method to opening files and you can see a "progression" in the
applications software.  Older DBASE programs ask the user to specify
FCBS=16, while newer versions which use file handles instead of FCBs
will request the user to have FILES=20 in the CONFIG.SYS FILE.  The
difference is important mainly to the programmer - with the older
system, the programmer was required to use FCBs to open & close files,
with file handles, the programmer simply asks DOS to open a file
and DOS creates the control block in its own memory on behalf of the
application and give the application a number, or file handle, with
which to refer to the file.  DOS then takes care of all the messy
details.

There is a limit to the number of handles open for each process, or
application.  That limit is 20.  That means that only 20 files,
including the application programs, its support files, and the user's
files, are able to be opened at one time.  DOS also uses 3 file
handles out of that 20, so the user can't expect to open dozens of
index files on a data base, for example.  From what I have been able
determine, if you are running other programs in the background, such
as the print spooler provided by DOS, (PRINT), those also take up file
handles, but they are considered to be independent processes, which
means they each have their "own set" of 20 handles.  IBM's network
also takes file handles, so if you are running the network, you will
want to have 20 handles available for the network + 20 for your
applications, so you should have a minimum of 40 handles.  But again,
increasing the number of handles uses up memory, so you need to
balance the number of handles to allow for the system against the
amount of RAM you need.

SHELL:  This command can be used to tell DOS that you want to run your
own command processor, rather than using DOS' COMMAND.COM, or you can
use it to specify the directory where COMMAND.COM is stored on your
hard disk.  If you have put this file in a directory called DOS, you
could use the command "SHELL=C:\DOS\COMMAND.COM" to tell the system
where to look for the command processor, COMMAND.COM.

SHELL also has a parameter, "/E:nnnn", which allows the user to
indicate how many bytes they want their environment size to be.  It
can be from 160 to 32768 bytes.  Specifying "SHELL=C:\DOS\COMMAND.COM
/E:320" would give you an environment of 320 bytes.

The environment is an area used by DOS to pass names and parameters to
applications.  If you set a path to be searched when executing a
program, or you customize the prompt, or you use set to keep a certain
string in memory, all these things are kept by DOS in the environment.
 Some applications ask you to use the SET command to set up the
 directory name where you keep your data.  Then, when you use the
 program, it can look in the environment, pick up the string and know
 where on your hard disk to look for data files.

DOS makes a copy of the environment for every program you run, so you
do not want to make this area too large if you are running memory
resident programs.  Each program gets it's own copy and if the
environment is large, they will take up more RAM.  One tip, if you are
running memory resident software, such as Sidekick, or Superkey, do
not set a long path, or put a long string in the environment before
executing the program.  In your AUTOEXEC.BAT file, execute Sidekick
and then do your path commands and prompt commands.  That way,
Sidekick's copy of the environment will be smaller and you will be
using up fewer bytes of RAM.

If you are setting up long paths and get the error message that you
are out of environment space, you can use the "SHELL=C:\COMMAND.COM
/E:NNN" to get more space.  This command is valid for DOS 3.1 and 3.2.

AUTOEXEC.BAT

The AUTOEXEC.BAT file is executed after COMMAND.COM has been loaded.
COMMAND.COM contains the batch file processor, as well as the internal
DOS commands, so it is necessary for COMMAND.COM to be present and
running before the AUTOEXEC.BAT file is executed.  If the AUTOEXEC.BAT
file is not located in the root (\) directory, it will not be run.

The AUTOEXEC.BAT file contains normal DOS commands, in straight ASCII
text, which the user would like executed when the system is booted.
Generally, it will contain a "PATH=" command to set up a search path
to the user's directories, memory resident programs, and maybe a
"PROMPT" command to set up a custom prompt.  An example of an
AUTOEXEC.BAT file is:

cd \sk
sk
cd \
cd \utils
scrnblnk
cd \
path c:\batch;c:\dos;c:\nu;c:\utils;c:\pe;c:\sk;c:\
prompt $p$g
rxbak

You will see that there are two memory resident utilities being
executed, SK (SIDEKIDK), and SCRNBLNK (Screen Blanker).  They are the
first lines in the AUTOEXEC.BAT file, along with the "CD" commands to
change into their directories.  Since every memory resident utility
keeps its own copy of the environment, they are placed before the long
"PATH" command, and because of this, it is necessary to do the "CD"
commands to find the programs.

The "PATH" command tells DOS where to look for programs which are not
in the current directory.  When setting up a search path, try to place
the most frequently used directory first.  For example, if you do a
lot of disk formatting, and have DOS commands in a directory called
DOS, then put "\DOS" first.  Then if you are in another subdirectory
and you execute the "FORMAT" command, it will find it faster than if
it was at the end of the list.  When using a hard disk, it is often
helpful to set up batch files to change subdirectories and start
programs for you, for example if you have Lotus' 1-2-3 in a
subdirectory called 123, you could set up a batch file called 123.BAT
containing:

cd \123
123
cd \

You could keep all such batch files in a subdirectory called \BATCH
and by putting this as the first or second subdirectory on the search
path, you would have quick access to your programs without having to
remember to do CDs all the time.

The PROMPT command is probably the most commonly used command after
PATH.  It allows you to change the prompt from a plain "C>" to
something you prefer.  You can have it display text, or even more
useful, you can have it display the subdirectory you are in.  For
example, the command:

PROMPT $P$G

in the AUTOEXEC.BAT file would display the following when in the root
(\) directory:    C:\>
or if you are in the \123 directory:  C:\123>

The $P is replaced with the current path, and the $G is replaced with
the greather than (>) symbol.  You can also have it display the time,
or even change the screen color if you have the "DEVICE=ANSI.SYS" line
in your CONFIG.SYS file.

One last thing, if you wish to execute another batch file and come
back to the AUTOEXEC.BAT file to continue to the next command, you can
add the following line to your AUTOEXEC.BAT file (this also works with
any other batch files, allowing you to execute a secondary batch file
and come back to the first one):

COMMAND /C SECOND

This would execute a second command processor (COMMAND.COM) which
would run the SECOND.BAT file.  In SECOND.BAT you should have the
command "EXIT" to then get out of this secondary COMMAND.COM and
continue processing the first AUTOEXEC.BAT file command (or the
calling batch file).

That's all the tips for this article.  Hope you get something out of
this that can help you tame DOS.

ajg
 of 320 bytes.

The environment is an area used by DOS to pass names an