textfiles/computers/config.txt

Your CONFIG.SYS and AUTOEXEC.BAT by 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 named 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 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 latter 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 called 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 DOS 3.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.

-----------------------------------------------------------------------------
Then downloaded from The Cave BBS (Wellington) for the library of
The Pinnacle Club (Auckland)...................................B.
-----------------------------------------------------------------------------