🚀 go-pugleaf

First, thanks to the many people who responded to my request for information
on extended and expanded memory.  I had intended to thank everyone individu-
ally but the requirements of work intervened and I didn't get around to it
immediately and some that I did get to had "bangland" return addresses which
resulted in my mailbox filling with MAILER-DAEMON messages.

The confusion, in large part, involves semantics and the documentation pro-
vided in the readme files included with the manufacturer's MS-DOS distribu-
tion for his IBM PC compatible.  Reading the replies evoked a "Back to the
Future" response--I had just forgotten many of the details of the transition
from single-user, batch oriented operating systems to multi-user, multi-
programming, real-time oriented operating systems that I had experienced
twenty years ago.

As several people pointed out, expanded memory was originally a hardware
technique to "expand" the memory available to the 8088, 8086, and 80186
processors which are restricted to a total address space of 1 Mbyte as they
only support 20 address lines.  Either through direct program control or a
device driver the hardware could map any of its 64 Kbyte pages of memory
into the 1 Mbyte address space supported by the processors.

With the 80286, the processor architecture was changed to "extend" the
available address space by providing 24 address lines.  This permits 16
Mbytes of memory to be directly accessed; however, the high-order 4 address
lines are only enabled when in "protected" mode.  [I have a vague recollec-
tion from documentation for a Tandy 2000 that I owned that the 80186 did
have "support" for 24 address lines but lacked the means for enabling the
additional address lines.]  Great for the multi-user operating systems--such
as OS/2 and XENIX where you don't want users or programs to have direct
access to devices or memory outside of their assigned address space--a pain
for the single-user MS-DOS environment.

With the 80386, the processor architecture was, again, changed to "extend"
the available address space by providing 48 address lines.  This permits 4
Gbytes of memory to be directly accessed.  In the above paragraph I failed
to mention that the 80286 did not provide an instruction to disable "pro-
tected" mode once it was enabled.  In addition to the additional address
lines, the 80386 architecture was enhanced to provide instructions to en-
able/disable "protected" mode.

One respondent pointed out that I probably understood more than I thought.
That is probably true, the problem is really with the software solutions to
the problems of accessing the expanded/extended memory and the various stan-
dards that have been developed for handling/requesting additional memory.
You have XMS, EMS, EEMS, LIM, VCPI, etc. standards to choose from which
address how a program requests access to expanded or extended memory, how
software uses extended memory to emulate the hardware behaviour of expanded
memory boards, and how software uses expanded memory to emulate the hardware
behviour of extended memory.

As a colleague likes to point out:  "The nice thing about standards is that
you have so many to choose from!"

EMS (Expanded Memory Specification) defines the behaviour of expanded memory
hardware.  I ran accross a reference to an Enhanced Expanded Memory Specifi-
cation (EEMS) but don't recall whether it was a hardware specification or a
software specification.

XMS (eXtended Memory Specification) is a software specification defining the
use of extended memory.  HIMEM.SYS is the device driver that implements this
specification.  A second device driver, XMA2EMS.SYS, implements this speci-
fication for EMS compliant hardware.

LIM (Lotus, Intel, and Microsoft Expanded Memory Specification) is a soft-
ware specification that defines the emulation of expanded memory hardware in
extended memory.  EMM386.SYS is the device driver that implements this spec-
ification.

VCPI (Virtual Control Program Interface) is another software specification
developed by Quarterdeck and Phar Lap which (I think) defines the memory
management interface for the virtual 8086 mode introduced with the 80386 and
used by windowing software in an attempt to implement a multi-user environ-
ment within the MS-DOS single-user environment.

Now the fun part begins--matching your hardware capabilities to the memory
environment expected by the various programs that you use and attempting to
develop a CONFIG.SYS which will maximize the performance of each program
without constantly rebooting the system to change your configuration.  How
much memory does one allocate for each memory standard that is required?
Which of the myriad of driver options do I need to use?  Are there MS-DOS
resource conflicts among the drivers that implement these standards?  Do I
have programs that have embedded, roll-your-own memory management logic that
bypasses any drivers that you install or conditionally bypasses these driv-
ers if the wrong one is loaded?

Rather than grapple with the task of repetitively changing my CONFIG.SYS, I
purchased Quarterdeck's QEMM-386 memory management program after noticing in
another discussion thread a comment that it supported all of the above spec-
ifications, allocated memory downward from the highest memory address, and
didn't require memory for each specification to be physically contiguous.

So far, QEMM-386 has lived up to its promised capabilities and my expecta-
tions.  It has allowed me to move the normally resident MS-DOS extensions
which are, in actuality, seldom used into extended memory along with all the
Novell software I had to have just to get to a printer.  The net result was
120K of "real" memory available for those programs that were developed prior
to the introduction of expanded or extended memory or weren't enhanced to
make use of the memory.  It may be illusory but system performance seems to
have improved, as well.

Again, my thanks to all who responded to my request for information.  Hope-
fully, the above is relatively accurate and someone will find it helpful.