925 lines
39 KiB
Plaintext
925 lines
39 KiB
Plaintext
|
|
|
|
Your CONFIG.SYS and AUTOEXEC.BAT
|
|
Barry Simon
|
|
|
|
Copyright (c) 1986, by Barry Simon
|
|
|
|
Written expressly for and posted on Compuserve's IBM Forum. May
|
|
only be reproduced commercially with the author's permission. May
|
|
only be distributed with this copyright notice intact.
|
|
|
|
Introduction
|
|
|
|
During the startup of an IBM or IBM compatible computer, the
|
|
operating system looks for two files of user supplied commands which
|
|
allow you to customize your system in various ways. This article
|
|
will attempt to explain some of the options available to you when
|
|
you make these basic files. While I have written it for the
|
|
relative novice, I hope it may provide some useful new tricks even
|
|
to the more experienced user.
|
|
|
|
These two files whose names must be CONFIG.SYS and AUTOEXEC.BAT
|
|
should reside in the root directory of your boot diskette or of your
|
|
hard disk if you have a bootable hard disk (i.e. if you can start
|
|
your system from your hard disk without placing a diskette in drive
|
|
A).
|
|
|
|
Actually, there is a method for placing the AUTOEXEC.BAT file in a
|
|
subdirectory but despite the fact that I tend to be fanatical about
|
|
keeping my root directory lean, I don't recommend using this option.
|
|
|
|
When you turn on your computer, the CPU is setup to begin a program
|
|
in the ROM (read only memory) that all IBM compatible machines have.
|
|
|
|
This ROM is distinct from and in addition to the working RAM (random
|
|
access memory). When you are sold a machine with 256K of memory,
|
|
that figure refers to the RAM. There is an additional 16K-32K of
|
|
ROM. RAM is cleared whenever you turn off your machine or reboot
|
|
while the ROM is permanently burned in and should not change.
|
|
|
|
|
|
Booting Up
|
|
|
|
The program that is automatically run from ROM begins with a brief
|
|
test (POST="power on self test") of various components of your
|
|
computer.
|
|
|
|
If you have an XT or AT, the most noticeable part is the memory(RAM)
|
|
test accompanied by counting up the memory on your screen as the
|
|
test progresses. This test is skipped when you do a warm reboot by
|
|
hitting Ctrl-Alt-Del. You may also notice your drives and printer
|
|
"burping" as they get tested.
|
|
|
|
After this test, the machine searches for various "ROM extensions"
|
|
that is additional ROM that can come with a hard disk or EGA card
|
|
for example.
|
|
|
|
The program then searches first drive A and then a hard disk if you
|
|
have a bootable hard disk for a diskette or disk program to transfer
|
|
control to. It transfers control to the very first sector on the
|
|
disk which is called the boot sector.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When you format a diskette, a little program is placed in the boot
|
|
sector which will display the message "non system disk, replace
|
|
and hit any key".
|
|
|
|
When you transfer the operating system to the disk with the SYS
|
|
command or via FORMAT/S, this boot sector program is changed to
|
|
transfer control to a program which must be in the position
|
|
immediately following the boot sector.
|
|
|
|
If the disk has the system on it, control is transferred
|
|
successively to two hidden files which load the BIOS ("basic
|
|
input/output system" part of which is in ROM) and the DOS ("Disk
|
|
operating system").
|
|
|
|
When most users think of DOS they think of the familiar prompt and
|
|
copy,.... commands. These parts of the DOS are only loaded later;
|
|
the part in the hidden file involves services provided by DOS to
|
|
programmers rather than directly to users.
|
|
|
|
The two hidden files are called "IBMBIOS.COM" and "IBMDOS.COM" in
|
|
PC-DOS and may have different names on other computers although
|
|
surprisingly, the names persist even on some non-IBM brands!
|
|
|
|
Parenthetically, I want to note that there isn't really much hidden
|
|
about hidden files. As you may know, the DIRectory you are used to
|
|
display gets its information from a special file also called the
|
|
directory.
|
|
|
|
This file is essentially a little database with information about
|
|
each file including the filename, extension, date and time of
|
|
creation. One byte in the record for each file is called the
|
|
attribute byte and contains eight "switches" to keep track of things
|
|
like whether the file is a volume label, read only, etc.
|
|
|
|
One of these switches is whether the file is "hidden". To anyone
|
|
with any programming experience or with any of a large number of
|
|
public domain or commercial programs, these files are not in any
|
|
sense hidden.
|
|
|
|
The basic DOS services like DIR and COPY are specially set up to
|
|
ignore hidden files and that is the only sense in which these files
|
|
are hidden.
|
|
|
|
The two system files are hidden because their location is critical
|
|
for a successful boot-up and they are less likely to be moved by
|
|
accident if they are hidden.
|
|
|
|
After the second hidden file is mainly loaded, it looks for a
|
|
special file called "CONFIG.SYS" and processes the commands in it.
|
|
|
|
Then control is passed to the third file in the operating system,
|
|
COMMAND.COM. As the final step in booting up, COMMAND.COM looks
|
|
for a file names AUTOEXEC.BAT and if found it loads it and runs
|
|
it. If not found, COMMAND.COM exits with the DATE and TIME
|
|
commands.
|
|
|
|
Except for its special status as a bootup file, the AUTOEXEC.BAT
|
|
file is an ordinary BATch file with the usual rules of syntax.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The CONFIG.SYS file has a special syntax with a limited number of
|
|
allowed commands. Both must be pure ASCII files, that is without
|
|
any special formatting codes that some word processors add.
|
|
|
|
Many word processors which have special codes have a "non-document"
|
|
mode for preparing ASCII files. These files have separate lines
|
|
which must be ended with carriage return/line feed pairs. If you
|
|
have any doubts about whether the file is "pure ASCII" you can use
|
|
the TYPE command to display it on the screen and see if it just has
|
|
ordinary letters and numbers.
|
|
|
|
|
|
What goes in your root directory
|
|
|
|
When a subdirectory fills up, it adds another cluster of disk space
|
|
to increase its size but the size of the root directory is fixed at
|
|
the time the diskette or disk is formatted. It is not merely
|
|
because of the size restriction that I recommend that you keep your
|
|
root directory slight.
|
|
|
|
Since the files in the root are likely to be of diverse type, it
|
|
will be difficult to keep track of things if you put too much there.
|
|
I mainly put subdirectories there and mainly subdirectories which
|
|
have no files but only subsubdirectories.
|
|
|
|
For example, I have a words subdirectory with my word processor,
|
|
outliner, thesaurus, etc in subsubdirectories.
|
|
|
|
Generally, there are only three files that I recommend go into the
|
|
root: COMMAND.COM, CONFIG.SYS and AUTOEXEC.BAT. As I mentioned,
|
|
one can put AUTOEXEC.BAT elsewhere and even COMMAND.COM but I feel
|
|
that is carrying things too far.
|
|
|
|
In fact, I even have a startup.bat file of the type I'll describe
|
|
there but the point is to keep that directory thin and to complain
|
|
bitterly about software so inconsiderate that it forces you to place
|
|
it in the root directory.
|
|
|
|
My point in mentioning this here is that I'm about to discuss device
|
|
drivers which many people put in the root directory. If you like to
|
|
be organized, I recommend you make a directory for device drivers
|
|
(mine is called \bin\devices).
|
|
|
|
Another option is to put the drivers in different directories with
|
|
each driver in with related files so, for example, the drivers that
|
|
come with DOS are kept in the same directory as the other DOS
|
|
programs or the mouse driver is with the other mouse software.
|
|
|
|
|
|
Device drivers
|
|
|
|
There are a group of programs which are made permanently resident
|
|
and which are loaded as part of the CONFIG.SYS. Virtually any
|
|
resident program can be produced in this format but certain ones
|
|
must be of this form.
|
|
|
|
Typically, console drivers and any program which controls "a device"
|
|
must be loaded now. Most virtual disks and print spoolers also are
|
|
loaded as device drivers.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
While device drivers are programs, they need not have the extension
|
|
"com" or "exe". In fact, so far as I can tell their extension can
|
|
be anything that you wish. Nevertheless virtually all commercially
|
|
available device drivers have the extension "sys".
|
|
|
|
Some drivers are available with the extension "dev". The syntax
|
|
for loading a device driver in your CONFIG.SYS is
|
|
|
|
device=<path><name><parameters>
|
|
|
|
so if you have a device foo.sys in the directory \bin\devices of
|
|
drive C: and it will take a numeric parameter to set the size of
|
|
some buffer, you might load it with
|
|
|
|
device=C:\bin\devices\foo.sys 128
|
|
|
|
Note that it is essential to include the extension "sys" or else
|
|
you will get an error message "bad or missing foo". The drive
|
|
letter C: is not required but it can't hurt and I know of one
|
|
person who claimed the device driver on her machine couldn't be
|
|
found without it.
|
|
|
|
The question of which parameters a given device driver allows or
|
|
whether it allows any at all depends on the driver and should be
|
|
dealt with in the documentation for the program in question.
|
|
|
|
For the drivers ANSI.SYS and VDISK.SYS which come with DOS, I note
|
|
that the former takes no parameters while the later takes parameters
|
|
explained in the DOS manual. DOS 3.2 comes with a third driver
|
|
called DRIVER.SYS while some versions of MSDOS 3.2 comes with an
|
|
alternate ram disk called RAMDRIVE.SYS. Both take parameters.
|
|
|
|
|
|
Examples of Device Drivers: the default drivers
|
|
|
|
I will not attempt to describe all available device drivers since
|
|
there are so many. For example, Chris Dunford, one of the sysops
|
|
of Compuserve has written public domain programs which installs
|
|
"devices" to control screen blanking (BURNDEV) and another allowing
|
|
you to send control sequences easily to your speaker (SPKR).
|
|
|
|
These represent examples where a real "device" is installed. A
|
|
device is a virtual file which can typically be written too and read
|
|
from. The most common example is "con" which you typically read
|
|
from when you issue the command "copy con filename".
|
|
|
|
Devices can only be installed via the CONFIG.SYS. Despite the name,
|
|
the device command can load other programs which do not control
|
|
devices and physical "devices" may not be devices in the sense of
|
|
setting up a virtual file. A mouse is a good example of something
|
|
which is not a device in this technical sense.
|
|
|
|
The hidden file IBMDOS sets up several devices even if you have no
|
|
CONFIG.SYS: con, prn, aux, lpt1, lpt2, lpt3, com1, com2. Con, short
|
|
for console is a combined keyboard/monitor device, prn for printer
|
|
is by default a name for lpt1 and aux a name for com1.
|
|
|
|
The DOS mode command allows reassignment of these devices. LPTn
|
|
and COMn are names for the parallel and serial ports on the
|
|
|
|
|
|
|
|
|
|
|
|
|
|
computer. These device names are assigned even if you don't have
|
|
the full complement of ports.
|
|
|
|
|
|
Examples of Device Drivers:Console Drivers
|
|
|
|
The most common device driver to install is a console driver which
|
|
replaces the default console driver. Some of these replacements
|
|
attempt to address the notoriously slow display speed of the
|
|
monitors and/or the annoying flicker on the color graphics display.
|
|
|
|
In addition some of the escape sequences of the 1977 console
|
|
standard of the American National Standards Institute (ANSI) are
|
|
implemented. These sequences include ways of controlling colors,
|
|
cursor position and some DOS level keyboard macros. (They are
|
|
described in my article ANSI.ART).
|
|
|
|
One console driver of this type called ANSI.SYS is supplied with DOS
|
|
and takes about 2K of resident memory. It does not address the
|
|
speed of display issue but it does implement several ANSI escape
|
|
sequences.
|
|
|
|
There are numerous programs which assume the ANSI.SYS is installed
|
|
to operate properly (as well as a few that don't work properly if
|
|
ANSI.SYS is installed!) so it is wise to install ANSI or an
|
|
equivalent driver even if you do not want to use its features
|
|
yourself. Actually, it is not hard to use the driver at the DOS
|
|
level to set colors, set up a fancy prompt or redefine keys.
|
|
|
|
There are several alternatives available to ANSI.SYS which you might
|
|
want to consider. NANSI.SYS is a public domain program which speeds
|
|
up scrolling (when combined with RAW mode by a factor of about 2)
|
|
and provides some additional ANSI escape commands at a cost of only
|
|
3K of RAM.
|
|
|
|
FANSI CONSOLE and TALL SCREEN are two commercial programs (listing
|
|
for $75 and $49 respectively) taking much more memory (around 60K
|
|
with a reasonable amount of screen save memory) providing many more
|
|
services: faster scrolling (FANSI only), screen blanking (FANSI
|
|
only), DOS command line editing and recall (TALL SCREEN ONLY),
|
|
screen memory and keyboard enhancements as well as additional
|
|
features.
|
|
|
|
While it is most natural to control scrolling by a device driver,
|
|
there is at least one commercial com program which takes over the
|
|
console by a different method and speeds up scrolling my a factor of
|
|
six or more (FLICKER FREE).
|
|
|
|
I am quite happy with FANSI but I have friends whose computer taste
|
|
I trust using both NANSI and TALL SCREEN so the choice is not clear.
|
|
And FLICKER FREE is an intriguing program whose second release
|
|
(which will support the EGA) I eagerly await.
|
|
|
|
|
|
Examples of Device Drivers:Other drivers
|
|
|
|
If you have a Lotus/Intel/Microsoft EMS board or AST EEMS board, you
|
|
will need to load a device driver to access this extended memory.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Often the command will require various parameters to specify the
|
|
amount of memory being set aside and various items like the region
|
|
of conventional memory used for swapping and the port number to use.
|
|
|
|
Be warned if you are setting up a CONFIG.SYS file for the first time
|
|
that you may already have a CONFIG.SYS file which was made for you
|
|
when you installed the EMS software that came with your board.
|
|
|
|
Since this likely has the correct parameters, you should make your
|
|
own CONFIG.SYS file by starting with this one and continuing from
|
|
there. It is possible that you will need to load the EMS driver
|
|
before anything else.
|
|
|
|
I can report that if I try to load FANSI-CONSOLE on my AT before the
|
|
EMS driver that Intel supplies with my Above Board AT, the EMS
|
|
driver refuses to load and gives me the error message that my
|
|
machine is "not a close enough AT compatible"!
|
|
|
|
Also be warned that while there is an EMS "standard", this refers to
|
|
the way EMS works once the driver that comes with your board is
|
|
installed. More likely than not, drivers from different companies
|
|
are incompatible and if you need a second EMS board, it will have to
|
|
come from the company that supplied your first (this warning does
|
|
not apply to extended memory on the AT but only to expanded EMS
|
|
memory).
|
|
|
|
Some older hard disks are not self booting and require a device
|
|
driver loaded in your CONFIG.SYS but that is not so common any more.
|
|
DOS 3.2 has a program called DRIVER.SYS which is a device driver to
|
|
initialize external 3.5 inch drives if you have one on an XT or AT.
|
|
|
|
By far the most common drive device driver is to operate a RAM disk,
|
|
that is a segment of RAM set aside as a fast virtual disk. There
|
|
are com files loaded after the CONFIG.SYS which set up such drives
|
|
but generally it is more sensible to use a device driver for this.
|
|
|
|
DOS 3.x comes with a program VDISK.SYS to set up a RAM disk. This
|
|
disk can operate in conventional or AT extended memory. It wil not
|
|
set up a RAM disk in EMS memory but most EMS boards come with device
|
|
drivers to set up RAM disks in EMS.
|
|
|
|
In addition Microsoft WINDOWS comes with a RAM disk device driver
|
|
(which can be run independently of WINDOWS) and which can be set up
|
|
in conventional, AT extended or EMS memory. Given Microsoft's
|
|
experience and the care they have lavished on WINDOWS, I'd recommend
|
|
using the WINDOWS RAM disk driver if you have it in preference to
|
|
alternatives and, in particular to VDISK which also comes from
|
|
Microsoft.
|
|
|
|
However, if you are loading other programs that use AT extended
|
|
memory, you may want to stick with VDISK because the specification
|
|
that IBM uses to access AT extended memory is published while that
|
|
of Microsoft is not and so other programs may clobber the Window's
|
|
RAM DISK driver.
|
|
|
|
If you want to set up more than one RAM disk, you can include more
|
|
than one line loading a RAM disk driver in your CONFIG.SYS file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
You can normally load the same driver twice or use different driver
|
|
if you prefer. Be warned that there is typically a few K overhead
|
|
in conventional memory to load a RAM disk and you will pay this
|
|
overhead more than once if you load more than one RAM disk.
|
|
|
|
Print spoolers set aside some memory to receive printer output and
|
|
then send that output to your printer as a background process. I
|
|
regard them as a tremendous productivity tool. While there exist
|
|
print spoolers loading as com files, many are loaded as device
|
|
drivers.
|
|
|
|
The Microsoft Mouse requires software to install it so your system
|
|
will recognize the mouse. The mouse comes with two versions of this
|
|
software: MOUSE.SYS which is loaded as a device driver in your
|
|
CONFIG.SYS and MOUSE.COM which is loaded later, typically in your
|
|
AUTOEXEC.BAT.
|
|
|
|
I do not believe there is any particular reason to prefer one over
|
|
the other. Microsoft recommends using the device driver on all
|
|
systems but the 3270 machines. If you are using Software Carousel,
|
|
you'll want to use the com file in various partitions rather than
|
|
the device driver.
|
|
|
|
As you may know you can place remarks in your BATch files and in
|
|
particular in your AUTOEXEC.BAT. This is useful if you want to
|
|
temporarily run your system without some resident program that is
|
|
usually loaded in your AUTOEXEC.BAT file. You need only "remark it
|
|
out", i.e. add the phrase "REM " at the beginning of the line
|
|
including it.
|
|
|
|
Technically, remarks are not allowed in CONFIG.SYS files. If you
|
|
insert the word "REM" at the start of a line in your CONFIG.SYS file
|
|
you will get the message
|
|
|
|
Unrecognized command in CONFIG.SYS
|
|
|
|
However, since the rest of the line is not acted on, this procedure
|
|
will have the desired effect of "commenting out" the line in
|
|
question so you should not hesitate to use it.
|
|
|
|
ECHO also doesn't work in CONFIG.SYS so there is no direct way of
|
|
placing messages on the screen during the loading of the CONFIG.SYS
|
|
However, there is a public domain program called COMMENT.SYS which
|
|
allows you to echo comments to the screen via
|
|
|
|
device=path\comment.sys <message>
|
|
|
|
There is no stay resident part of comment.sys so you don't waste
|
|
memory, only time, by using it. If you are a color freak, you can
|
|
first load an ANSI compatible console driver and then use
|
|
COMMENT.SYS to send color setting escape sequences to the screen
|
|
and so see most of your bootup in living color!
|
|
|
|
|
|
The FILES command
|
|
|
|
DOS is a prisoner of its past. Original IBM PC's came with only
|
|
16K of memory (!) so when DOS boots up it sets aside memory for
|
|
various purposes in an incredibly frugal manner. The defaults for
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
three regions of memory set aside for file handles, disk buffers and
|
|
environment are woefully inadequate. If you know what you are
|
|
doing, it is easy to change these defaults but it's unfortunate that
|
|
the novice gets stuck with these small values.
|
|
|
|
In any event, FILES and BUFFER commands are among the most important
|
|
for you to include in your CONFIG.SYS. When DOS opens a file, it
|
|
keeps certain information in memory to be able to quickly access the
|
|
file. This information is called a file handle.
|
|
|
|
During bootup, memory is put aside for these file handles so a limit
|
|
is placed on the number of files that can be open at one time. The
|
|
default is eight which may seem adequate since programs normally
|
|
close files when they are done allowing the file handles to be
|
|
reused.
|
|
|
|
However, eight is often not adequate. DOS uses four of the handles
|
|
itself for "files" like con and prn. Thus there are four available
|
|
for your programs.
|
|
|
|
Some resident programs leave files open and even the ones that
|
|
don't, may need to open a file for an initial access at the same
|
|
time that an application program have several files open.
|
|
|
|
Database programs often have separate index and data files and
|
|
typically may want to have more than four open files. If DOS is
|
|
asked to open a file and a handle is not available, DOS issues an
|
|
error message and the running program may even abort. I strongly
|
|
recommend that you place the line
|
|
|
|
FILES=20
|
|
|
|
in your CONFIG.SYS file. Indeed since the cost of increasing files
|
|
is less than 40 bytes per handle, you could even use a number larger
|
|
than 20. For most purposes 20 should suffice but ever since it
|
|
wasn't enough for me in a rather specialized situation, I've taken
|
|
files=30 myself.
|
|
|
|
|
|
BUFFERS
|
|
|
|
You may have heard of disk caching. As you've noticed, diskette
|
|
access is very slow and even a hard disk has access times 100 fold
|
|
grater than RAM access times.
|
|
|
|
Disk caching sets aside some RAM to keep a copy of the most recently
|
|
accessed disk information so, for example, if a database is
|
|
continually accessing a disk, the first time the disk is really read
|
|
but the next time the copy in cache memory will be read instead.
|
|
|
|
This is not the place to discuss the pros and cons of commercial
|
|
disk caching software but you should know that DOS comes with some
|
|
free rudimentary disk caching included. It keeps N buffers of 512
|
|
bytes each with the copies of the last N disk sectors accessed.
|
|
|
|
By default N is only two (three on the AT). You should certainly
|
|
make this number larger by including the line
|
|
|
|
BUFFERS=N
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
in your CONFIG.SYS where recommended values of N are between 10
|
|
and 25.
|
|
|
|
Let me tell you an anecdote to show how dramatic a difference this
|
|
number can make. The first time that I ran my tape backup drive
|
|
to backup my 30 meg hard disk, I was bitterly disappointed.
|
|
|
|
Despite what I'd been told by the salesman, it took over 45 minutes!
|
|
The next day, when I thought about it and tried again, it took only
|
|
8 minutes!
|
|
|
|
What had happened? The first time I had been nervous about the
|
|
effect my many resident programs might have so I put an original
|
|
write protected DOS disk in drive A and rebooted before running the
|
|
backup software.
|
|
|
|
This disk had no CONFIG.SYS so I was running with the default three
|
|
buffers. The next day, I used my regular hard disk boot with
|
|
buffers=20 and that made the difference. I have done some time
|
|
tests comparing something as simple as copying a directory from a
|
|
hard disk to a floppy and I've found that using extra buffers can
|
|
decrease times by 30 or 40 percent. So USE YOUR FREE DISK CACHING.
|
|
|
|
The issue of precisely how many buffers to take is not an easy one.
|
|
Increasing the number of files handles has little effect on memory
|
|
or efficiency so you can freely take files=99 if the mood strikes
|
|
you. This is not so with buffers.
|
|
|
|
Each buffer takes .5K of RAM so buffers add up. Moreover at some
|
|
point it will take DOS longer to check through all its buffers
|
|
looking to see if a file is there than it would take it to access it
|
|
directly. I've seen the number 25 given as a dividing line but I
|
|
would like to do some tests to check this out. I can only say that
|
|
I've settled on buffers=20 myself and that with a floppy based
|
|
system, you should take a higher figure than you might with a hard
|
|
disk.
|
|
|
|
|
|
Increasing your environment
|
|
|
|
DOS sets up a special section of memory called the environment which
|
|
has a default size of 160 bytes. This area must hold your path,
|
|
your prompt, the place that COMMAND.COM can be found and various
|
|
other strings.
|
|
|
|
Programs can communicate with you by asking you to place information
|
|
in the environment with the SET command. In addition you can keep
|
|
global variables in the environment to pass between BATch files.
|
|
|
|
If you attempt to place more there than it has room for you'll get a
|
|
message "Out of environment space". With DOS 3.1 and later there is
|
|
a CONFIG.SYS command allowing you to increase the amount of space
|
|
reserved for your environment.
|
|
|
|
There are known patches for earlier versions DOS which are listed
|
|
for example in my article on ANSI.SYS. The procedure is documented
|
|
in DOS 3.2 and so presumably it will be a permanent feature of DOS.
|
|
It is undocumented in DOS 3.1. The syntax is
|
|
|
|
shell=C:\command.com /P /E:nnn
|
|
|
|
|
|
|
|
|
|
|
|
|
|
where n is the number of bytes you want to set aside for the
|
|
environment.
|
|
|
|
For DOS 3.1 nnn represents the number of 16 byte paragraphs you want
|
|
to set aside. So for a 512 byte environment take nnn=32 in DOS 3.1
|
|
and 512 in DOS 3.2. Obviously with a floppy based system, replace
|
|
C: by A:
|
|
|
|
How much space do you need for your environment? That depends on
|
|
your path, applications and how fancy a prompt you make. My advice
|
|
is to do nothing until you have a problem at which point you should
|
|
remember that there is something that you can do.
|
|
|
|
For more advanced users, I note that the environment is not as
|
|
benign as you might think. I know of several programs which crashed
|
|
if there was too much in the environment (most of the ones I know
|
|
about have been fixed) and one that crashed if the PATH was the last
|
|
thing set in the environment. I have occasionally been baffled at
|
|
what could be causing a conflict only to discover the culprit was
|
|
the environment.
|
|
|
|
|
|
Miscellaneous CONFIG.SYS commands
|
|
|
|
There are some other commands that can go in your CONFIG.SYS:
|
|
|
|
- You can turn BREAK ON that is have the operating system check
|
|
for control C more often than just during disk I/O. This slows
|
|
down certain processing but gives you more safety from certain
|
|
kinds of dead ends. The syntax is a line saying
|
|
|
|
BREAK=ON
|
|
Unlike any other CONFIG.SYS command, this one can also be issued
|
|
from the DOS command line or in your AUTOEXEC.BAT file.
|
|
|
|
- In addition to file handles, DOS has something call file
|
|
control blocks which in DOS 3.x can be changed by an FCBS
|
|
command. These are needed only if you have a LAN (local area
|
|
network) and the parameters to take should be discussed by your
|
|
LAN software.
|
|
|
|
- DOS 3.2 has a STACK command. From what I've read this is a
|
|
real cludge and the manual seems to suggest that it was added at
|
|
the last minute to solve a problem connected with a new way that
|
|
DOS3.2 treats the stack. In any event, if you use DOS 3.2 and
|
|
seem to have unexplained crashes, try adding
|
|
|
|
STACK=20
|
|
|
|
to your CONFIG.SYS.
|
|
|
|
- DOS 3.1 and later allows you to use the SUBST command to assign
|
|
drive letters to directories. In addition, with several RAM
|
|
disks you may want to assign a letter beyond the default last
|
|
drive of E. DOS 3.x allows you to add a command
|
|
|
|
LAST DRIVE = ?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
where ? is a letter and then you can assign any drive up to and
|
|
including that letter. Even a last drive=z only takes about 1K
|
|
of RAM.
|
|
|
|
- There is a COUNTRY command to control things like the time
|
|
format. The default is USA.
|
|
|
|
One final remark about your CONFIG.SYS. The order of the commands
|
|
is irrelevant except to the extent that certain device drivers like
|
|
to be loaded before others (and if you are loading two RAM disks of
|
|
different sizes you may care which is assigned which letter). As
|
|
with most DOS commands the syntax is not case sensitive.
|
|
|
|
As a review of what a CONFIG.SYS can contain, let me list the
|
|
CONFIG.SYS from one of my machines which is running DOS 3.2:
|
|
|
|
break=on
|
|
buffers=20
|
|
device=C:\bin\intel\emm.sys M3 I5 D
|
|
device=C:\bin\devices\fconbeta.dev
|
|
/C=1/S=2000/H=0/V=0/R=200/L=1/W=1
|
|
device=C:\bin\devices\ramdrive.sys 1024 512 128 /A
|
|
device=C:\bin\devices\ramdrive.sys 1300 512 64 /E
|
|
device=C:\bin\devices\atqlpt1.sys 1644,1,3
|
|
device=C:\bin\devices\mouse.sys
|
|
files=30
|
|
lastdrive=z
|
|
shell=C:\command.com /P /E:512
|
|
|
|
|
|
|
|
What should your AUTOEXEC.BAT contain?
|
|
|
|
Most of my AUTOEXEC.BAT file loads my own particular blend of
|
|
resident programs. This is not the place for me to advise you on
|
|
what resident programs you might want to put into your system but
|
|
I would like to make some comments about DOS and general aspects of
|
|
what goes into your AUTOEXEC.BAT file.
|
|
|
|
First, if you have very many resident programs, they may have
|
|
conflicts and you must be prepared to permute the order of loading
|
|
which often cures some or all of the conflicts.
|
|
|
|
For technical reasons I won't go into here it really does pay to
|
|
listen to SIDEKICK's demand to be loaded last although you need not
|
|
take all the other Borland program demands quite so seriously.
|
|
|
|
In addition to loading a stable of resident programs your
|
|
AUTOEXEC.BAT can contain some of the following:
|
|
|
|
- a VERIFY ON command. This slows down copying because DOS
|
|
checks that the copy at least has consistent CRCs; this is not
|
|
the same as comparing after copying but it is a fairly good
|
|
check.
|
|
|
|
Only several compensating errors could pass this test after an
|
|
incorrect copy.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- set a PROMPT. At a minimum use
|
|
|
|
prompt=$p$g
|
|
|
|
Mine uses ANSI.SYS to set colors and place the path and date on
|
|
the bottom line of my screen
|
|
|
|
- set a PATH. If possible, keep your path short since every
|
|
time you type in a bad command, DOS will have to read every
|
|
directory in the path before responding "Bad command or
|
|
filename". Also try to list the path in the order of how many
|
|
times you expect to access a given directory. That is place
|
|
the directories you call most often early in your path. If
|
|
you have a RAM disk, place its directories first in the path.
|
|
|
|
If you have a relatively large RAM disk, think about copying
|
|
your BATch file directory and the programs you call often to
|
|
that RAM disk and place that RAM disk first in your path.
|
|
|
|
- If you have a large RAM disk, consider copying COMMAND.COM to
|
|
it and placing the command
|
|
|
|
SET comspec=D:\command.com
|
|
|
|
in your AUTOEXEC.BAT (assuming D: is your RAM disk). Even
|
|
without a large RAM disk, it is worthwhile to do this on a
|
|
floppy based system. What the command does is tell DOS to look
|
|
there when it needs to reload COMMAND.COM (large programs will
|
|
overwrite a part of COMMAND.COM and when they exit, DOS will
|
|
try to reload COMMAND.COM. With the above command, you'll no
|
|
longer get "Place a disk with command.com in drive A: and hit
|
|
any key to continue".)
|
|
|
|
- It really is important to put the proper date and time in your
|
|
system. Be sure to include the DATE and TIME commands or else
|
|
be sure to get a clock and place the appropriate commands
|
|
setting the system time from the clock into your AUTOEXEC.BAT
|
|
file.
|
|
|
|
- if you want to keep track of how often you boot, keep a record
|
|
in a convenient directory. Make a file called junk consisting
|
|
only of a carriage return line feed and include the lines
|
|
|
|
date >>directory\logon <junk
|
|
time >>directory\logon <junk
|
|
|
|
You will then get the lines
|
|
|
|
Current date is Wed 7-23-1986
|
|
Enter new date (mm-dd-yy):
|
|
Current time is 16:29:22.70
|
|
Enter new time:
|
|
|
|
for each time you bootup. With CED, EBL or some other programs
|
|
you can get this record in a more elegant fashion without the
|
|
|
|
"Enter new ..." lines.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Speed and Memory tips
|
|
|
|
Some final remarks about tricks to minimize memory usage and speedup
|
|
your bootup procedure. When DOS loads any program it saves a copy
|
|
of the current environment in memory, one copy for each program.
|
|
|
|
It doesn't force the copy to be as large as the empty space that
|
|
you've set aside via a shell command but only to keep in full the
|
|
present value of all environmental variables. Thus you can save
|
|
memory by keeping the environment small while your AUTOEXEC.BAT file
|
|
is loading your resident programs. Two variables are always
|
|
present: path and comspec. I start my AUTOEXEC.BAT file with a line
|
|
|
|
Path=A
|
|
|
|
This is incorrect syntax and gets ignored when the path is needed.
|
|
|
|
I have to be sure to put down full path names of all the programs
|
|
that I load but that speeds processing any ways. I reset the path
|
|
and set the prompt at the end of my AUTOEXEC.BAT after I've loaded
|
|
my resident programs.
|
|
|
|
Given my fancy prompt, I save almost 200 bytes per resident program
|
|
from what would happen if I set my path and prompt at the beginning
|
|
of my AUTOEXEC.BAT. In total I save several K of RAM: not a lot but
|
|
every little byte helps.
|
|
|
|
BATch files are read by DOS a line at a time so BATch files really
|
|
do get processed much faster from a RAM disk than from a floppy.
|
|
|
|
There is a smaller difference between a hard disk and a RAM disk.
|
|
If you have a RAM disk and a floppy based system, it is well worth
|
|
your while to place what would have been your AUTOEXEC.BAT in a file
|
|
called startup.bat and have your AUTOEXEC.BAT read:
|
|
|
|
copy startup.bat C:
|
|
C:startup.bat
|
|
|
|
assuming your RAM disk is C:. To conserve space, you can have the
|
|
last line in startup.bat say
|
|
|
|
erase C:startup.bat
|
|
|
|
You'll get a "batch file missing" error message but other than that
|
|
the method will work perfectly. This procedure can also be used on
|
|
a hard disk. The savings when I did it on my hard disk was two
|
|
seconds out of about 65 so you may not feel it is worth your while.
|
|
|
|
You can slightly speed up processing of BATch files especially from
|
|
floppies by using the FOR...IN...DO command to combine several
|
|
commands in one line. For example, if you want to copy
|
|
\bin\batfiles, \bin\dump and \bin\opsys to your RAM disk you might
|
|
try
|
|
|
|
for %%a in (\bin\batfiles \bin\dump \bin\opsys) do copy %a C:\
|
|
>nul
|
|
|
|
if C: is your RAM disk. This can actually cut about 10% off a long
|
|
AUTOEXEC.BAT file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Several warnings are in order.
|
|
|
|
First, FOR...IN...DO parse the list at spaces so you can't combine
|
|
commands which have parameters in this way.
|
|
|
|
Secondly, I strongly recommend against using this device to load
|
|
resident programs particularly if you plan to use Kokkenen's
|
|
MARK/RELEASE package.
|
|
|
|
|
|
Summary
|
|
|
|
By using your CONFIG.SYS and AUTOEXEC.BAT files you can personalize
|
|
many aspects of your PC.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|