DOS memory

Memory issues: Note: some of this information may be rather redundant with hardware: memory: DOS.

Famously, MS-DOS had support for at least the following methods of categorizing and handling memory: Conventional Memory, Upper/High Memory, XMS, and EMS. Also, DPMI was an additional option that became popular later in DOS's lifespan. Another memory standard was DOS Protected Mode Services (“DPMS”, unrelated to the VESA Display Power Management Signaling which also has been frequently abbreviated to “DPMS”).

Checking free memory in MS-DOS

The most well-known solution is likely to use mem /c (which will show details about the memory usage). That command will likely work great, with a single exception: The MS-DOS mem command will not complete successfully when the XMSMMGR command is being used.

A less known fact is that many implementations of the chkdsk software may report the amount of free conventional memory.

Configuring memory types
Conventional memory

The term “conventional memory” is used for the first segment of memory. Some computers may have had less conventional memory due to not even having that much physical RAM. The typically cited maximum of conventional memory was 640KB, although 736KB could potentially be available.

This segment of memory was rather famous for not being abundant enough. There are a few approaches to being able to maximize conventional memory:

Using awesome drivers

This technique wasn't quite so well utilized during the prime days of MS-DOS, perhaps because some of these drivers didn't exist. Some modern drivers provide full functionality while using much less memory than older drivers. So, upgrade. Some top, excellent, recommended choices to check out include the following:

CuteMouse
Get full mouse support for a fraction of the memory usage of many other drivers. See: CuteMouse's home page to get a copy.
CD-ROM support
CD-ROM device drivers

There are some options which are much better than others. See TOOGAM's collection of CD-ROM drivers describes some of the better options available. There may be updates, such as UIDE.sys from Jack R. Ellis's DOS software (specifically the “Jack R. Ellis Drivers” page at http://johnson.tmfc.net/dos/driver.html )

(So, don't use OAKCDROM.SYS when you're trying to use optimum software. Using that software may be the most effecient way to accomplish some tasks since that driver came bundled with some Microsoft Windows operating systems, but the software is notably worse than some other options.)

CD-ROM Extensions

Use an alternative to MSCDEX. Some alternatives may be some compatibility issues with CD audio when certain CD-ROM device drivers are used: In such cases a way to fix the issue might be to use a different CD-ROM driver. (Even if an alternative CD-ROM driver uses more memory, the cost in memory may be less than the cost of using MSCDEX). Especially for copying data, the alternatives generally work fine with no negative side effects: just less memory used. Options include using SHSUCDX or perhaps NWCDEX.

TOOGAM.com's Software Archive: DOS CD filesystem drivers provides some hyperlinks.

Memory Drivers
Chipset-specific Memory Drivers
[#umbpci]: UMBPCI.SYS
To get UMBs, on hardware that supports using such a thing, use Uwe Sieber's UMBPCI.SYS (English web page) (information for this is also avialable at Uwe Sieber's UMBPCI.SYS (Deutsch/German web page)) instead of EMM386.*.
HIRAM
MDGx Guide to UMBPCI.SYS: section about HIRAM.EXE shows how this may be used to make UMBPCI.SYS's upper memory “visible to DOS through a small XMS 2.0 handler” so that even HIMEM.SYS may be loaded high and lead to UMBPCI.SYS not using up any memory (even though UMBPCI.SYS already initiated DOS's ability to make UMA available). Download the software from the MDGx site mentioned above (e.g. using “ wget -U "Firefox Netscape" -N http://mdgx.com/files/HIRAM_E.ZIP ”), or from the “Links” section at the bottom of Uwe's site about UMBPCI.Sys, or from TOOGAM's software archive.
URAM
May be similar to UMBPCI? Index listing (in English) of Velt Kannegieser software, URAM distribution (Arj'ed), URAM Assembly source code (which requires Country source code).
Replacing other driver files

A RAM drive, and an ANSI driver are both generally completely unnecessary. However, if either is desired, try using an alternative implementation rather than what came with the operating system.

Don't use the \DOS\RAMDRIVE.SYS before checking out something like TDsk. (See FreeDOS's web page about TDSK.)

Don't use the \DOS\ANSI.SYS before checking out something options from alternatives like PC Magazine's ANSI.com or the now-GPL NANSI (NANSI, FreeDOS site about NANSI). PC Magazine page about ANSI.com states, “ANSI.com was written by Michael J. Mefford, and first appeared in PC Magazine February 7, 1989 (v08n02). Source code is included.” Source code is Assembly. See: v08n02.zip, WWIV BBS archive: ANSI 1.3L.

Command line interpretor
4DOS has become freeware (with available source code), so don't hesitate to start using this excellent piece of programming anytime that DOS is used. There may be some benefit to using 4DOS (especially of optional memory/buffer/code sizes are kept small and/or such memory is moved to non-conventional memory). By using 4DOS, there is probably no need to waste memory using DOSKEY.
Adjusting BIOS options
Some code might be getting copied from ROM chips to RAM chips because the ROM chips were slower (and cheaper). Memory may be able to be reclaimed by adjusting options in the BIOS. References to “shadow copy” may be relevant.
Re-arranging what gets loaded into various segments of memory

Decent results might be obtained by backing up the startup files and then running MS-DOS 6's MemMaker command. (It may create a MEMMAKER.STS file, and use the SIZER.EXE command.)

Find out how much UMB/HMA is free. If the amount is substantial (such as tens of kilobytes), then find out what driver uses up the most amount of conventional memory. Use Mem /C unless using MS-DOS's Mem with XMSMMGR? Then move things into the high memory by using LH and/or by using the CONFIG.SYS's DEVICEHIGH command.

Cannibalizing other memory areas

Why would anybody want more than 640KB of conventional memory? After all, Bill Gates is widely cited to have stated, “640K ought to be enough for anybody.” (Bill Gates denied this quote, Wayback Marchine @ Archive.org cache of interview questions with Bill Gates, Wired.com article about quoting Bill Gates about 640K of memory. (e.g., An example of the quote, (1min 50 seconds into) EMF Verses. 1min48sec into YouTube video: EMF Verses).

It might even be possible to have more than 640KB of memory if certain video support is sacrificed. Examples are mentioned by Peter Brueggeman's RAM Cram guide, which states, “Technically DOS is not limited to using just the first 640K of conventional memory and it is a soft limit. There are work-arounds to increase usable memory beyond 640K for application software.” The “INCREASING MEMORY FROM HIGH VIDEO MEMORY” section of the page documents commercial products which can increase memory by up to 96KB if CGA video is used. (Increasing by just 64KB, instead of 96KB, might be doable by using monochrome.) Over half a dozen memory management products are listed in that article. (No freely distributable software is known to provide this capability.) Indeed, DOS's mem can report over 640KB of conventional memory available.

DEW Associates Corporation's page about MS-DOS Memory Issues mentioned conventional memory could be “up to 736KB with special device drivers and hardware”. Some additional discussion may be found by Cy Atkinson's documentation about high memory which is referenced by Wikipedia's page on “Conventional memory”: section titled “Additional memory”.

[#umamem]: Upper memory area (“UMA”)

This exists after the Conventional memory and before the high memory, so it exists in the upper portion fo the first megabyte of RAM. If the amount of conventional memory is 640KB, then this may be 384KB. Naturally, this data segment will be smaller if there is more conventional memory.

DEW Associates Corporation's page about MS-DOS Memory Issues stated, “IBM chose to reserve the upper 384KB for ROM and other uses.”

[#hmamem]: High memory area (“HMA”)
The first 65,520 bytes of extended memory.
[#xmsmem]: “Extended Memory” (“XMS”)

Win9x came with XMSMMGR.exe which seems to be really just as good as HIMEM.SYS, and does not cause any sort of compatibility issues, with the following exceptions:

  • The MS-DOS mem command will not complete successfully when the XMSMMGR command is being used.
  • This is run from the command line, so doing things traditionally would mean that XMS isn't available to the programs designed to be loaded when the CONFIG.SYS file is being processed. This isn't absolutely true now that such programs can often be started from the command line, and since it is now possible to run a command line program during the processing of the CONFIG.SYS file (if that file is getting processed like most DOS implementations).

Since XMS didn't tend to cause nearly as much problems as EMM386, a lot of people used it (possibly in addition to EMS). Solutions relying on XMS were among the most compatible, working with many systems. (The more compatible solutions could be those that simply didn't require so much memory, or those using DPMI.)

[#emsmem]: “Expanded Memory” (“EMS”)

Know that very little software will require using EMS instead of XMS. The EMM386.* file may have a side effect of switching the processor from “real mode” to “protected mode”. This can cause some compatibility issues. To avoid that, one possible solution may be to look into abandoning EMS altogether, or possibly by using a driver other than the EMM386.* bundled with DOS operating systems. For further details about some other options, see hardware: memory in DOS.

DOS Protected Mode Interface (“DPMI”)

CWSDPMI worked great. The only problem is that it wasn't bundled with operating systems, so some software preferred to use the older XMS and EMS standards. However, if people acquired the CWSDPMI file, that seemed to work well in just about any DOS-compatible environment. (Well, probably not pre-386 systems. However, pre-386 systems also didn't tend to have as much memory, and didn't commonly use EMS either.)

DPMI by DR-DOS

OpenDOS FAQ list (as of 14th March 1997) @ Delorie.com noted, “There are known to be some bugs with EMM386” (The FAQ mentions that CWSDPMI is recommended over the that operating system's DPMI.)

DJGPP v2 FAQ 6.3: Buggy DPMI host or junk in DJGPP.ENV can crash v2.x programs noted, “Version 7.03 and later of Caldera's DR-DOS reportedly don't have this bug in their DPMI server, so upgrade to a latest DR-DOS version if you can.”

DPMI by Quarterdeck's QDPMI
DJGPP v2 FAQ 6.3: Buggy DPMI host or junk in DJGPP.ENV can crash v2.x programs noted, “If you use QDPMI, upgrade to the version 7.53 or later”.
[#dosprtmd]: DOS Protected Mode Services (“DPMS”, unrelated to “Display Power Management Signaling” which uses the same abbreviation).

(This is abbreviated as “DPMS”. As noted, DOS Protected Mode Services this is unrelated to VESA Display Power Management Signaling, which is known to sometimes also be referred to by an abbreviation of DPMS.)

...

[#vcpi]: VCPI
DEW Associates Corporation's page about MS-DOS Memory Issues says, “VCPI services are provided by QEMM/Desqview and most of the DOS extenders currently on the market; DMPI is somewhat newer (and more capable) and currently is supported primarily in Microsoft Windows.”