Category : Alternate Operating Systems - Quarterdeck DesqView, CP/M, etc
Archive   : QWHITE13.ZIP
Filename : EXTMEM.TEC

Output of file : EXTMEM.TEC contained in archive : QWHITE13.ZIP

ID:X2 EXTMEM Parameter, in Short
Quarterdeck Technical Note #240 Filename: EXTMEM.TEC
by Michael Bolton CompuServe:
Last revised: 5/21/92 Category: QEMM

Subject: A review of the EXTMEM and MEMORY parameters to QEMM-386 -- what
they're used for, and why you almost certainly don't need them.

Q. When do I need the EXTMEM parameter?

You probably don't!

QEMM-386 -- the Quarterdeck Expanded Memory Manager 386 -- has in a way
outgrown its name! One of QEMM's most powerful features is its ability to
allocate BOTH extended and expanded memory from a single, common pool. Since
QEMM is by name and nature an exPANded memory manager, and since it provides
so many different kinds of memory in so many different ways, it is easy to
lose sight of the fact that QEMM provides exTENded memory too. Understanding
the various flavours of memory can be helpful to understanding why you
probably don't need the EXTMEM parameter. More information on this topic is
available in the Quarterdeck White Paper QEMMEXT.TEC; you are reading an
abridged version of that file.

Q. What is Extended Memory?

DOS was designed for the 8088 and 8086 processors -- processors which could
address a total of 1024K or 1MB of addresses. The 286 added extra address
lines, and therefore could address up to 16MB of memory. The 286 could do
this by going into a mode called "protected mode", in which programs could see
all of the processor's address space, and all of the memory installed on the
machine. However, protected mode was (and is) fundamentally incompatible with
DOS. To retain compatibility with DOS, the 286 had an extra mode, called
"real mode". This is the mode in which the processor is started, and it is a
kind of 8086 emulation mode. The developers of the chip probably presumed
that programmers would be using protected mode operating systems shortly after
the 286's introduction, but DOS and its users prevailed, and remained limited
to a single megabyte of addresses.

The memory above the first megabyte, essentially invisible to DOS, was given
the name "extended memory". Since the 8086 and 8088 processors have only
enough address lines to access 1MB of addresses, there can be no extended
memory on machines built around these processors.

Since DOS could not generate an address larger than 1024K, DOS programs were
not able to access the memory above 1024K for running code. However, the PC
architecture's BIOS (Basic Input-Output Services) did provide for a means by
which programs could use extended memory to store data; RAM disks, and later
disk caches and print spoolers put this technology to work.

In the old days -- before 1988 -- there were no defined standards whereby a
program could allocate the extended memory on a 286 or greater processor, so
extended memory was allocated via one of two different strategies. One, often
referred to as the "bottom-up" or "VDISK" method (after the RAM disk that
first used it), used the INT 19h BIOS call to grab extended memory from the
1MB line upwards, and left signatures in two places identifying the memory as
allocated. Other programs that wanted to access extended memory could do so
by checking in the appropriate places for VDISK signatures, updating the
information, and allocating memory from the new "bottom" of extended memory.
The top-down method (also known as the INT 15h method, named after the BIOS
call used to access extended memory) involves grabbing a chunk of memory from
the top of available extended memory downwards. The system is then set up
such that applications which follow will be informed that less extended memory
is available than the amount actually installed on the machine.

Both of these methods have serious dangers and complications, and so the
eXtended Memory Specification (XMS), the Virtual Control Program Interface
(VCPI), and the DOS Protected Mode Interface (DPMI) specifications were
devised. These specifications allow programs to access extended memory in a
well-defined and orderly way. Modern RAM disks, disk caches and print
spoolers typically get their extended memory through the XMS specification;
large application programs which use extended memory typically do so via XMS,

Q. My program uses exTENded memory, but when I start it, it says there
isn't enough exTENded memory. What now?

If your program complains that there is not enough exTENded memory (or none at
all) available, and if you have a MEM=nnnn or EXTMEM=nnnn parameter on the
QEMM line, try deleting it (or both, if you have specified both). Conversely
(and this will be needed only very rarely) try setting aside unmanaged
extended memory with EXTMEM=nnnn (where nnnn is the amount of memory in K that
you wish to leave UNMANAGED). Remember, only extended memory programs that
use the INT 15 method of accessing extended memory require QEMM to be
configured specially. There are very few of these left on the market; the most
common is VDISK from DOS version 3. If you are running applications that use
extended memory, it is highly probable that you don't need, and should not
use, the EXTMEM parameter.

*This technical note may be copied and distributed freely as long as it*
*is distributed in its entirety and it is not distributed for profit. *
* Copyright (C) 1992 by Quarterdeck Office Systems *
************************ E N D O F F I L E *************************