                 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 will 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.

e uses ANSI.SYS to set colors and place the path and date on 
   the bottom line of my screen
   -set a PATH.