
   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.

         ----------------end-of-author's-documentation---------------

                         Software Library Information:

                    This disk copy provided as a service of

                           Public (software) Library

         We are not the authors of this program, nor are we associated
         with the author in any way other than as a distributor of the
         program in accordance with the author's terms of distribution.

         Please direct shareware payments and specific questions about
         this program to the author of the program, whose name appears
         elsewhere in  this documentation. If you have trouble getting
         in touch with the author,  we will do whatever we can to help
         you with your questions. All programs have been tested and do
         run.  To report problems,  please use the form that is in the
         file PROBLEM.DOC on many of our disks or in other written for-
         mat with screen printouts, if possible.  PsL cannot debug pro-
         programs over the telephone, though we can answer questions.

         Disks in the PsL are updated  monthly,  so if you did not get
         this disk directly from the PsL, you should be aware that the
         files in this set may no longer be the current versions. Also,
         if you got this disk from another vendor and are having prob-
         lems,  be aware that  some files may have become corrupted or
         lost by that vendor. Get a current, working disk from PsL.

         For a copy of the latest monthly software library newsletter
         and a list of the 3,000+ disks in the library, call or write

                           Public (software) Library
                               P.O.Box 35705 - F
                            Houston, TX 77235-5705

                                 Orders only:
                                1-800-2424-PSL
                              MC/Visa/AmEx/Discover

                          Outside of U.S. or in Texas
                          or for general information,
                              Call 1-713-524-6394

                          PsL also has an outstanding
                          catalog for the Macintosh.


