Tune up your boot up with config.sys. (DOS tips) (column)
by Tony Roberts
A propely tuned CONFIG.SYS helps your system run smoothly. With CONFIG.SYS out of balance, however, you'll waste memory in the best case, or have trouble running some programs in the worst case.
Many users avoid CONFIG.SYS except when directed by software installation procedures to make some change, usually to the BUFFERS or FILES commands. These suggestions are designed to ensure that the new software works properly under the heaviest imaginable load. If you don't push your software to its absolute limit, you may be able to scale back these settings.
Although the memory you can save by judiciously refining CONFIG.SYS commands amounts to only a few thousand bytes, this is sometimes enough to allow the coexistence of memory-resident utilities and programs that otherwise seem incompatible.
The FILES command specifies the maximum number of files that can be open at any one time. Although it may appear that very few files are open, there's more going on than meets the eye. If you start your word processing program with a batch file, for example, the batch file is open, the word processing program is open, the file you are editing is open, and other auxiliary files such as printer drivers or spelling dictionaries may be open.
DOS uses 64 bytes of memory to track the status of each open file. It sets aside this block of memory based on the FILES statement in CONFIG.SYS. If you specify FILES=20, DOS reserves 1280 bytes regardless of how many files are actually open.
If the FILES allocation is too small, DOS alerts you with a Too many files open message when it runs out of slots in which to track files.
To find the optimum setting for FILES, gradually reduce the number of files specified in CONFIG.SYS and then run your usual software until you encounter errors. Then raise the FILES setting a little so you can operate error free.
BUFFERS, at 512 bytes each, are much more memory-hungry than FILES. A buffer is a block of memory used in the exchange of information between programs and disks.
When data is needed from the disk, a disk sector is read, and the information is placed in a buffer where the program can access it. Although the program often requires fewer bytes than the entire 512 bytes the sector holds, the extra information is kept in the buffer in case the program asks for it later.
When the application makes its next request for disk access, the buffers are checked to see if the appropriate data is there. If so, the data can be accessed immediately without requiring a slow disk-read operation.
The most recently read disk data is kept in the buffers, and once all buffers are full, the oldest data is discarded to make way for new information.
When too few buffers are specified in CONFIG.SYS, the system will be slowed by extra disk accesses. If too many buffers are allocated, the system loses time churning through them before going to the disk.
Finding the proper number of BUFFERS is largely a matter of feel. With too few buffers open, your machine will perform sluggishly, but you may not need as many buffers as some software instructions suggest. This is especially true if you use disk caching.
A disk cache is a more sophisticated buffering system that manages a much larger amount of memory, often extended or expanded memory. Some disk caches work in conventional memory.
In addition to storing sectors already requested by the application program caches commonly perform look-ahead buffering. In this scheme, the cache reads the requested sector plus the next few sectors on the assumption that those sectors will be sought soon.
Caching programs also make intelligent decisions about what data to keep in memory. A well-executed cache not only keeps the most recently accessed information but also the most frequently used.
One other bit of tuning that helps speed up disk access is the FASTOPEN command that came into being with DOS 3.3.
FASTOPEN creates a directory cache that speeds up DOS's file-opening operations. The command, which is usually executed in the AUTOEXEC.BAT file, has a slightly different syntax in DOS 3.3 and DOS 4.01.
In DOS 3.3, FASTOPEN C:=100 sets up a 100-entry directory cache for disk drive C. In DOS 4.01, FASTOPEN C:=(100,) accomplishes the same result. FASTOPEN only works with hard disks.
Whenever a file opening is requested, DOS searches the directory path until it locates that file. If FASTOPEN is running, the file's location on the disk is recorded in the FASTOPEN cache. If a subsequent request for that file is made, DOS can quickly look up its location in the FASTOPEN cache rather than having to read through all the files in all the directories on the directory path.