[alt.msdos.programmer] Extended memory info

rb@cc.ic.ac.uk (Robin Becker) (06/08/90)

Hi,
	does anybody know where MSDOS keeps info about extended memory
if any.  Example on my PS/2 I have 1Mb i.e. 640k for DOS and 384k for
other things.  I use both a Disk cache and a Ram drive (set up in the
config.sys).  I have to specify the amount of memory to use and what
kind,  but not where it starts.  So how do these kinds of
program/drivers know how much extended memory is available and what
parts are free.
	Robin

silver@xrtll.uucp (Hi Ho Silver) (06/09/90)

In article <1990Jun8.122007.650@cc.ic.ac.uk> rb@cc.ic.ac.uk (Robin Becker) writes:
$	does anybody know where MSDOS keeps info about extended memory
$if any.  Example on my PS/2 I have 1Mb i.e. 640k for DOS and 384k for
$other things.  I use both a Disk cache and a Ram drive (set up in the
$config.sys).  I have to specify the amount of memory to use and what
$kind,  but not where it starts.  So how do these kinds of
$program/drivers know how much extended memory is available and what
$parts are free.

   MSDOS has no idea what extended memory is.  Extended memory (with the
exception of XMS, with which I have no familiarity) is not really managed
like conventional or expanded memory is.  Instead, there's a word in the
computer's memory that says how much extended memory there is.  This is
set by the BIOS's POST (Power-On Self Test) routines at boot time.

   What many (most?  all?) programs that use extended memory do is check
that word to see how much extended memory there is, reduce it by the
amount they need, and situate themselves in the highest portion of
extended memory.  This means that once the program has finished
installing itself, programs coming along later will think there is less
extended memory than there actually is.  How much less?  As much as
your first program used up, so that the next program that takes a chunk
will situate itself immediately below the first one.

   As an example, let's say you have 384K of extended memory and you want
to install a 128K disk cache.  The disk cache will likely install itself
starting at the 256K mark of extended memory and adjust the word to make
other programs think there's only 256K of extended memory.

   There are a couple of problems with this:

1.  Poorly designed memory testing programs may wipe out anything that's
    situated in extended memory

2.  If I load program 1 at the top of extended memory and program 2 below
    it, then try to unload program 1, what happens?  Depending on how
    program 1 is written, you may

    a)  lose the portion of memory program 1 was using if it's smart
        enough to realize something's loaded below it and not update the
        word saying how much extended memory there is

    b)  have the next thing that uses extended memory wipe out program 2,
        if program 1 simply increases the word by the amount of memory
        it was using

   Anyway, that's the experience I've had with trying to figure out how
programs manage extended memory.  I'm sure there are many I haven't seen
that do it that way, and many that do it some other way.
-- 
   /Nikebo \ Nikebo says "Nikebo knows how to post.  Just do it."\silver@xrtll/
  /---------\_____________________________________________________\----------/
 /yunexus!xrtll!silver (L, not 1)\ Hi Ho Silver \   just silver for short   /
/Silver:  Ever Searching for SNTF \  Life sucks. \  someone buy me a BEER! /

dmurdoch@watstat.uwaterloo.ca (Duncan Murdoch) (06/09/90)

In article <1990Jun8.122007.650@cc.ic.ac.uk> rb@cc.ic.ac.uk (Robin Becker) writes:
>Hi,
>	does anybody know where MSDOS keeps info about extended memory
>if any.  


It's fairly complicated. There's a good discussion in
 
  Extending DOS
  Edited by Ray Duncan
  Addison Wesley
  First printing, April 1990
  ISBN 0-201-55053-9 

Hope this helps.  

Duncan Murdoch