QUICK-N-DIRTY GUIDE TO MEMORY MANAGEMENT UNDER DOS 5.0

by Dave Eyre 70303,2533



INTRODUCTION



With DOS 5.0 you have considerable control over your PC's
memory, and can put this memory to much better use than in
the past. But though the DOS 5.0 manual gives a good
description of each individual memory management feature, it
gives no clear picture of how all these features hang
together, or how they are best combined for maximum benefit
to your PC operations. The book "Managing Memory with with
DOS 5" by Dan Gookin gives a good comprehensive treatment,
but for the user who is only looking for quick answers the
essential points tend to get swamped by excessive detail.

I wrote this quick-n-dirty guide to help people who come to
me with questions about setting up their DOS 5 CONFIG.SYS
file - people who just need enough to get by and don't want
a 200-page doctoral dissertation. This guide is designed to
give average users a basic grasp of memory management under
DOS 5.0 - enough to allow them to design a fairly competent
CONFIG.SYS file. To avoid unnecessary confusion it skates
lightly over topics which are not relevant to a simple
treatment.



THE THREE PARTS OF MEMORY



As a working example I have chosen a 386 machine with 4
Megabytes of RAM. This 4096 K of RAM is divided up as
follows:

a) The first 640 K is called "Conventional Memory" and is
where you load and operate your "working" software
such as word processor, spreadsheet, etc.
b) The next 384 K (from 640 K to 1024 K), is called
"Upper Memory". This is reserved by DOS for its own
use and previously there was no way of tapping into
the large reserves of unused memory in this area, but
with DOS 5.0 this now becomes possible.
c) The remaining 3072 K is called "Extended Memory".



PROTECTING THE 640 K CONVENTIONAL MEMORY



In memory management, a good first priority is to save as
much Conventional Memory as you can for your "working"
software (at any rate, that's MY first priority).

Unfortunately, during a normal boot-up procedure, DOS grabs
several chunks of Conventional Memory for the DEVICES loaded
by CONFIG.SYS, plus memory-resident files such as Sidekick
or Norton Commander loaded by AUTOEXEC.BAT, plus the DOS
operating system itself (which needs quite a bit of memory).
So you can be left with something much less than 640 K to
work with. In extreme cases (loading too many device
drivers and memory-resident programs) the remaining
Conventional Memory may not be big enough to run some of
your working software.

Under DOS 5.0 you can get around this problem by using three
tricks:

a) On 286 and 386 machines, DOS can be tricked into handling
(addressing) an extra 64 K, over the top of its normal
1024 K. This is called the "High Memory Area" (HMA). To
get access to this memory you must load HIMEM.SYS as a
device in your CONFIG.SYS file. This device must be
loaded first, before you do any other messing around with
memory allocations. So (preferably) the first line of
your CONFIG.SYS file should read:

DEVICE=C:\DOS\HIMEM.SYS


So now you have 384 + 64 = 448 K in Upper Memory, but
this is still reserved by DOS and is not available for
use by your working software. DOS actually uses only a
smallish fraction of this Upper Memory, and there are
large unused sections that could be put to good use if
only there were some way of getting at them. The
remaining two tricks allow you to do this.

b) Put the following command in the CONFIG.SYS file:

DOS=HIGH

This command forces DOS to load its system into Upper
Memory instead of stealing a chunk of Conventional
Memory. Instead of occupying about 65 K of Conventional
Memory, DOS 5.0 will then occupy about 14 K, saving you
an extra 51 K for your "working" software.

c) Now modify the CONFIG.SYS file so that the DOS command
reads:

DOS=HIGH,UMB

The UMB stands for Upper Memory Block, and it "alerts"
DOS to the fact that you are going to load some of the
device drivers or memory-resident programs into Upper
Memory instead of having them steal chunks from
Conventional Memory. Later on we'll see how to load
devices etc. into Upper Memory.



STEALING EXPANDED MEMORY FROM EXTENDED MEMORY



Remember we started off with 3072 K of Extended Memory, but
then we stole 64 K for the High Memory Area. So now we are
left with 3008 K of Extended Memory.

Before you start loading device drivers or assign memory to
different applications, it is first of all necessary to set
up the Expanded Memory Manager EMM386.EXE. This can do many
things, but its two basic functions are:

a) It controls the Upper Memory Blocks (chunks of Upper
Memory) where you are going to put your various device
drivers and memory-resident programs (to stop them using
valuable Conventional Memory). But you can't put these
things in Upper Memory without first activating
EMM386.EXE, so it's good policy to load this device in
the third line of the CONFIG.SYS file, before you proceed
to load device drivers.

b) It sets up an Expanded Memory System (EMS), which
requires a bit of explanation. Although DOS can only
access ("address") the first 1024 K of memory, the
Expanded Memory Manager (EMM) gives it a boost which
allows it (effectively) to access a much greater chunk of
memory. In fact, the EMM manager will allow DOS to
access any amount of your Extended Memory. You can
specify how much memory you require, and then the EMM
manager will effectively cut this out of Extended Memory
and make it available to DOS as Expanded Memory (or EMS).
At the same time, the EMM manager needs to mark out a 64
K section in the Upper Memory, which acts as a kind of
"window" through which DOS can "see" or access all the
Expanded Memory (read Gookin for more details).

Generally speaking, you only need Expanded Memory if you are
operating software that needs it and knows how to use it.
In such cases the software manual will (or should) give
instructions on how the Expanded Memory is to be set up.
Otherwise, you don't need Expanded Memory.

So there are basically two ways of setting up your EMM
manager:

DEVICE=C:\DOS\EMM386.EXE NOEMS or:

DEVICE=C:\DOS\EMM386.EXE 512 RAM

The first option sets up the EMM system to control the Upper
Memory Blocks only, with no Expanded Memory. Since there is
no Expanded Memory, the EMM manager does not need to mark
out the 64 K "window" mentioned above, so this 64 K is FREE
in Upper Memory and can be used for loading device drivers
and memory-resident programs. This is the best option when
your normal software operations don't need Expanded Memory.

The second option sets up an Expanded Memory of 512 K (or
whatever you specify) and the RAM option means that it also
controls the Upper Memory Blocks. With this option the EMM
manager marks out the 64 K of "window" in Upper Memory.
This means that there's less space in Upper Memory to load
device drivers and memory-resident programs. This is the
best option when your working software needs Expanded
Memory, and the size of the Expanded Memory System (EMS)
must be tailored to the needs of the software.

At this stage the CONFIG.SYS file contains only three lines,
as follows:

DEVICE=C:\DOS\HIMEM.SYS
DOS=HIGH,UMB
DEVICE=C:\DOS\EMM386.EXE NOEMS

It's useful to boot up with this CONFIG.SYS file, then look
at its effect on memory by running one or other of the
following commands:

mem /c |more (to view memory details on screen)
mem /c >prn (to print memory details)

You will probably find that you have started out with
3145728 bytes (3072 K) of Extended Memory, but now have only
2907136 bytes (2839 K). The High Memory Area stole 64 K
(remember?), and now the EMM manager has stolen another 169
K, even though we've not allocated any Expanded Memory.

The important point is that, after the first three lines of
the CONFIG.SYS file, we have clipped 233 K off Extended
Memory and are left with 2839 K (of course, this will vary
from one system to another).



MAKING BEST USE OF THE REMAINING EXTENDED MEMORY



The three most common ways of using Extended Memory are:

a) Use part of it for programs which need it. Windows,
for instance, makes good use of Extended Memory.
b) Use part of it for SMARTDRV Disk Cache. The Disk Cache
gives a remarkable speeding up of disk operations, and
it is generally desirable to install SMARTDRV with at
least its default size of 256 K. SMARTDRV takes over
many of the functions of the BUFFER system and
FASTOPEN, so if SMARTDRV is installed the BUFFERS can
be set to some low value (say 3) and FASTOPEN can be
ignored.
c) Use part of it for RAMDRIVE. This means that a
specified part of Extended Memory is set aside for use
as a Virtual Disk - actually a large chunk of RAM
which mimics the behaviour of a conventional disk.
The main advantage is that the Virtual Disk operates
much faster than a hardware disk. The main
disadvantage is that, when the computer is switched
off (or there is a power failure), the contents of
this disk will be lost. Virtual Disk operations are
nevertheless popular because of their speed, and
usually have to be controlled through a batch file
which transfers the necessary files from hard disk to
virtual disk, then, after work has been done on the
files, transfers them back to hard disk in their
modified form. Such operations may require a better-
than-average understanding of DOS on the part of the
user.

There is no carved-in-stone rule for dividing Extended
Memory among the above three options; it varies according to
individual use and preference. A good strategy is to have a
series of CONFIG.SYS files, each tailored to give the best
memory usage for its particular application. Then, after
boot-up, the appropriate CONFIG.SYS file is chosen and
activated by re-booting.



LOADING DEVICE DRIVERS INTO UPPER MEMORY



The following is a fairly typical CONFIG.SYS listing:

DEVICE=C:\DOS\HIMEM.SYS
DOS=HIGH,UMB
DEVICE=C:\DOS\EMM386.EXE NOEMS
DEVICE=C:\DOS\ANSI.SYS
DEVICE=C:\MOUSE\MOUSE.SYS
DEVICE=C:\DOS\SMARTDRV.SYS 1024
DEVICE=C:\DOS\RAMDRIVE.SYS 1814 512 64 /E
BUFFERS=3
FILES=30
BREAK=ON
SHELL=C:\COMMAND.COM /E:1024 /P

Note that the memories assigned to SMARTDRV and RAMDRIVE
total 2838 K, which in my working example will leave 1 K
(1024 bytes) of unused Extended Memory.

As a first step in assigning device drivers to the Upper
Memory, boot with the above version of CONFIG.SYS (using
whatever variations you like) and then run the command "mem
/c |more" (or "mem /c >prn") to look at the memory usage.

First of all, you'll find that all the device drivers (ANSI,
MOUSE, SMARTDRV, RAMDRIVE) have been loaded into
Conventional Memory, and "mem" shows the size of each
driver. [Note: some people get a bit confused here. Take
SMARTDRV for example: the DRIVER for SMARTDRV (the bit that
controls it) is loaded into Conventional Memory, but the
1024 K required for the Disk Cache is located in Extended
Memory].

Also, you will find that Upper Memory has several chunks of
FREE memory available, and "mem" shows you the size of each
chunk.

You now have to look at the sizes of the device drivers and
figure out how many of these drivers can be fitted into the
FREE parts of Upper Memory. Let's suppose that ANSI, MOUSE
and SMARTDRV can be fitted into Upper Memory, but there's
not enough space to take RAMDRIVE. It's a simple matter to
load ANSI, MOUSE and SMARTDRV into Upper Memory: all you
have to do is change DEVICE to DEVICEHIGH in the CONFIG.SYS
file, which then reads as follows:

DEVICE=C:\DOS\HIMEM.SYS
DOS=HIGH,UMB
DEVICE=C:\DOS\EMM386.EXE NOEMS [can't use
DEVICEHIGH here]
DEVICEHIGH=C:\DOS\ANSI.SYS
DEVICEHIGH=C:\MOUSE\MOUSE.SYS
DEVICEHIGH=C:\DOS\SMARTDRV.SYS 1024
DEVICE=C:\DOS\RAMDRIVE.SYS 1814 512 64 /E
BUFFERS=3
FILES=30
BREAK=ON
SHELL=C:\COMMAND.COM /E:1024 /P

The best policy is to try loading one driver at a time into
Upper Memory, then reboot with the modified CONFIG.SYS, then
use "mem /c |more" to look at the effect on memory.
Sometimes you will find that a driver will not load into
Upper Memory, even though there seems to be enough FREE
memory to take it (read Gookin if you want an explanation).



LOADING MEMORY-RESIDENT PROGRAMS INTO UPPER MEMORY


Memory-resident programs (TSR's) are normally loaded into
Conventional Memory by the AUTOEXEC.BAT file at boot-up.
The procedure for loading them into Upper Memory is similar
to that for device drivers: boot-up in the normal way, then
use the "mem" command to list the memory allocations. If a
memory-resident program is loaded into Conventional Memory,
note its size and also the amount of FREE Upper Memory. If
there is enough FREE memory, the program can be made to load
into Upper Memory by use of the command "loadhigh". For
example, AUTOEXEC.BAT might contain a command line "test",
which calls-up a memory-resident program "test.exe". If the
command line is changed to "loadhigh test" the program will
be loaded into Upper Memory when you re-boot.

But a note of caution: some memory-resident programs might
cause severe disruption if loaded into Upper Memory, and
your PC might abort or go into some other failure mode at
boot-up. Therefore when modifying AUTOEXEC.BAT with
"loadhigh" commands it is advisable to have a DOS system
floppy disk handy, so you can boot-up independently of the
hard disk then get into AUTOEXEC.BAT and remove the
offending command.



LOOKING DEEPER


This quick-n-dirty guide is only a superficial treatment
designed to get typical users off the ground. If you have
understood most of it then you will be able to return to the
DOS 5.0 Manual and read it with a better understanding.
Personally, I found that the Manual leaves a lot of
questions unanswered, so I turned to "Managing Memory with
with DOS 5" by Dan Gookin (published by Microsoft). This
gave me most of the answers I was looking for, and in my
opinion will amply reward those who are prepared to put a
bit of effort into reading it.