Re: Memory management FAQ

In reply to Eric Auer on 2002-10-26:

Thanks for the memory management FAQ.

Maybe worth a few notes, HIMEM.SYS and/or EMM386.EXE provide
so called XMSUMB memory. XMSUMB is UMB memory through the
XMS interface (INT 2Fh/AX=4310h sub-functions 10h..12h),
while "normal" UMB is usually considered UMB memory as
it is available through the higher level DOS memory API
(INT 21h/AH=48h..4Ah and AH=58h) - maybe we should call it
"DOSUMB"? The latter might also come from the XMSUMB pool
originally, but not necessarily so.

Of course, as long as the memory works, there is no "good"
or "bad" UMB memory for the programs to load, but still,
sometimes it is necessary to distinguish between these two
types of UMB memory.

Many of the DR-DOS tools (like NLSFUNC, KEYB, SHARE, etc.)
are "self-loadhigh-enabled" and will try to relocate
(into the HMA, or) into UMB memory using the XMSUMB API.
(They could be easily extended to alternatively use the
DOS API - in fact, many 3rd party self-loadhigh-enabled drivers
query both APIs to work under DR DOS 5.0+ as well as under
MS-DOS/PC DOS 5.0+. It's simply, that this hasn't been done
yet, as it was not required under DR-DOS, because unless
you specify

   EMM386 /NOXMSUMB

XMSUMB remains available (up to the addressable maximum) even
when you specify DOS=UMB (or HIDOS=ON) in CONFIG.SYS. Under
MS-DOS/PC DOS, once DOS has allocated the memory, the memory
is only available through DOS' own API, and no longer through
the "underlaying" XMSUMB interface. That is, DOS really has
"taken over".)

Although some drivers cannot actively load into UMB memory
themselves, when no XMSUMB memory is available in the system
any more, you can still try to load such a driver high with
external tools like LOADHIGH/LH (which goes through the DOS
API), of course.
But usually, if a driver knows how to load-high itself, the
perferred method is to /let/ it load-high itself, because
only the driver itself knows its internal layout and how
to possibly split itself into several modules to be fit
into small chunks of remaining free memory. And it is only
the driver itself who knows, if it actually needs a PSP,
an environment segment etc. after installation, and since
it can throw away such unused portions, a driver loading
high itself usually has a smaller resulting resident memory
footprint than using an external, or passive, method (no matter
how sophisticated that external method may be with all those
/D, /E, /L, /S, etc. options).
Finally, most drivers need way more memory during initialization
and it might be difficult to provide a large-enough continous
chunk of free upper memory for both, the resident driver plus
its initialization code, so it may happen, that even with LH and
friends, the driver ends up being loaded in conventional memory,
although the resident portion alone would still nicely fit up
in there. If the driver loads high itself, it can expand and
initialize in conventional memory and use almost as much memory
as it likes, and then only relocate the smaller resident portion
up in the upper memory area, so it only needs to allocate exactly
the memory it needs for the resident portion, not more, and
it can even do this dynamically according to its configuration.

So, providing XMSUMB and "DOSUMB" at the same time and dynamically
handling this internally can be a nice feature. It is not supported
by all memory managers, unfortunately (at least not by MS-DOS/PC DOS
EMM386, but, for example, it is supported by DR-DOS EMM386).

Hence the distinction.

> UMBPCI: common for 586 (Pentium) and newer chipsets. Some AMD Athlon
>    chipsets are - alas - not supported.
> HIRAM:  Classic choice for 486 and 386 systems.
> RDOSUMB, URAM: Alternative choices, mainly for 486 and 386 systems.
>    One of them allows you to use UMB if you managed to make that RAM
>    accessible using some external means, too. For example with the
>    386 NeAT chipset, you can enable that RAM in your BIOS CMOS setup.
>    The driver would then be able to detect it and allow UMB to use
>    the area.

May I add, that DR-DOS HIMEM.SYS offers similar hardware level
[XMS]UMB support in conjunction with many common 286 and 386
chipsets? So, the memory can be mapped into the upper memory
space without requiring paging support in the CPU (386+).

Alternatively, this version of HIMEM.SYS can convert raw permanent
upper memory to standard conformant UMB memory or utilize a
previously loaded EMS or EEMS driver to "misuse" EMS for UMB.
(Some otherwise unsupported chipsets support permanent upper memory
through their BIOS setup program or other drivers, some add-on cards
can provide it, and on some old XT systems you can install 256 Kbit
chips into all four memory banks and modify the address decoder to
provide permanent upper memory, as well. In particular the last
setup to run the DR-DOS HIMEM.SYS on an XT is not obvious to
everyone, as most other HIMEM.SYS implementations require at least
a 286 CPU to run. So if you have an XT with permanent upper memory
or EMS/EEMS hardware, the DR-DOS HIMEM.SYS is your friend to convert
it into "normal" UMB memory - usable by normal drivers without special
support to load at fixed memory locations or built-in EMS/EEMS support.)

On PS/2 machines, it is possible to convert XMA (Extended Memory
Architecture) memory as found on IBM XMA compatible memory adapter
cards into EMS memory using the DR-DOS EMMXMA.SYS driver.
Afterwards you might be able to convert this into [XMS]UMB memory
using DR-DOS HIMEM.SYS, but I never tried. Anyone?

So, it might also be interesting for readers of the memory management
FAQ to extend your comparison table to the specification /versions/
implemented in the various memory managers, since different versions
offer different ranges of features. For your convenience, here's a
summary for the DR-DOS drivers:

DR-DOS 7.03 HIMEM.SYS 2.34 is a 16-bit implementation and provides
XMS 2.0 including HMA memory and XMSUMB - UMB via built-in hardware
support for various 286/386 chipsets, via external EMS driver, or
via permanent upper RAM (see above). It also supports the temporary
or permanent use of parts of the physical video memory as conventional
memory (up to 64 Kb or 96 Kb depending on the video card installed) or
as extra permanent upper memory (up to 124 Kb depending on the video
hardware) as long as you remain in text mode only.

DR-DOS 7.03 EMM386 3.27 is a 32-bit implementation and provides
XMS 3.0 (including XMSUMB and HMA support; coexistance with "raw"
INT 15h memory; the detection of Extended Memory is limited to 64 Mb,
but internally it works with more), EMS 4.0 (supports only 4 mappable
pages, but with or *without* a 64 Kb page frame (60 mappable pages
in internal versions, so you can tile up to 1 Mb - 64 Kb); unfortunately
no alternate register sets for faster switching (only in internal
versions, AFAIR); no EEMS API emulation (not part of EMS 4.0 spec,
but would be nice to have for completeness); it does provided limited
(hidden at the moment) support for more than 32 Mb of EMS memory (not
part of the EMS 4.0 spec, though)).
EMM386 can also be used to backfill conventional memory (if you
have less then 640 Kb of conventional memory installed - hm, this
may be coupled with more than 4 mappable EMS pages, I'm not
completely sure about this at the moment).
EMM386 can map memory in the video memory address range to temporarily
or permanently extend the available conventional memory (up to 64 Kb
or 96 Kb depending on if you have a mono or a color system), or to
permanently add more upper memory (up to 124 Kb) as long as you stay
in text mode. It can also map RAM over unused portions of ROM.
EMM386 supports VCPI 1.0 and DPMI 0.9 (true "Windows-like" DPMI 0.9,
actually, plus a few DPMI 1.0 functions).
The SDK version also support DPMS 1.0 (DOS Protected Mode Services)
to debug/run DPMS clients on ring 2 (normally, DPMS is provided
by the external DPMS.EXE server, then DPMS clients run on ring 0).
It provides comprehensive APIs for multithreading and preemptive
multitasking in multiple concurrently running virtual machines.
(Virtual memory with disk swapping is not available yet.)
Beyond VCPI and GEMMIS (Global EMM Import Specification) it provides
interfaces to load virtual device drivers and coexist with Windows
(only Standard Mode and Real Mode under the DR-DOS multitasker,
else also Enhanced Mode). VDS 1.0 is supported as well, of course.

---

On 2002-10-25, Arkady V.Belousov wrote:

>> VCPI - virtual control programming interface
>
>      "Programs", not "programming", AFAIR.
>
>> UMB - upper memory blocks (640k ... 1 MB area)
>
>      "Block" (singular). :)

Ok, but then it should say Virtual Control Program Interface,
actually. ;-)

Sorry for being nitpicking - I just couldn't resist... ;-)

>> MB  - megabyte (1024*1024 byte, or 1000*1000 byte, depends ;-))
|>> GB  - gigabyte (1000 or 1024 MB)
|>> TB  - terabyte (1000 or 1024 GB). [...]
>
> To be precise: traditionally size of memory computed by power 2
> base [...]
> Moreover, when we (humans) count size of free memory, we also
> often use decimal multipliers. For example, when someone says
> "621 Kb of free memory" this usually mean ~607 Kb (=621000/1024/1024).

Usually, the English seem to write "Kb", "Mb", "Gb", "Tb" in either
notation (you're right about the traditional meaning, of course).

In German the notation is to write "KB", "MB", "GB", "TB", in particular,
when the numbers are meant to be based on the binary system.
I have observed, however, that some use "Kb", "Mb", "Gb", "Tb", when the
numbers are meant to be decimal. It's not used consistently, though.

Greetings,

 Matthias

-- 
<mailto:[email protected]>; <mailto:[email protected]>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org

"Programs are poems for computers."