Old Extended-Memory Allocation Methods: Interrupt 15h & VDisk Headers
In the past, there were two ways for programs to allocate extended memory:top-down (using Interrupt 15) and bottom-up (using VDisk headers).
Interrupt 15h is a ROM BIOS service that includes several extensions totheoriginal PC ROM BIOS, including the means to find out how much RAM(conventional plus extended) is on the system. A program uses this serviceto find out how much extended memory there is, then "hooks" Interrupt 15hand reports to any other programs that there is <n>K less memoryavailable,effectively slicing <n>K of extended memory off the top. By doing this,theprogram has allocated its own extended memory from the top of the memorypool.
Bottom-up memory allocation works by checking for a header at the start ofextended memory stating that <n>K of RAM is in use. If a header is there,the program checks <n>K further for another header. If no header exists,the program puts in its own header. These headers are called VDisk headersbecause the original IBM DOS RAM drive utility (VDISK.SYS) uses thismethod.
A drawback to these methods is that after memory has been allocated to aprogram, deallocating it is usually not possible. The XMS was designed tomake allocating and deallocating extended memory easier for all involved.
HIMEM.SYS Creates XMS Memory
HIMEM.SYS implements all of the XMS except the optional UMB portion.HIMEM.SYS versions earlier than 3.0 are XMS 2.0 compliant and recognize upto 16 MB of RAM; versions 3.0 and later (first included with Windows 3.10and MS-DOS 6.0) are XMS 3.0 compliant and recognize up to 4 GB.
On loading, HIMEM.SYS determines the amount of extended memory available.Unless it was loaded with the /INT15= option, HIMEM.SYS sets out toallocate all available extended memory for use as XMS memory (note theactual allocation of all the available extended memory does not occuruntila program makes an XMS function call). HIMEM.SYS reserves the HMA with aVDisk header and hooks Interrupt 15h. Programs that want to use extendedmemory (other than the HMA) without using XMS can do so until a programactually requests XMS.
After a program actually asks for XMS memory, HIMEM.SYS uses its Interrupt15h hook to notify programs that only the amount of extended memoryspecified by /INT15=xxxx, minus the HMA (64K), is available for use.Memoryavailable through /INT15=xxxx is physically located above the HMA; XMS-managed RAM is physically located above any /INT15=xxxx RAM.
A20 and the HMA
The HMA is defined as FFFF:0010-FFFF:FFFF on 80286 and higher systems thathave physical addressable RAM at these addresses. This area can beaddressed in real mode (8086 emulation) on 80286 and higher systems if the21st address line (A20) is enabled, which produces 64K-16 bytes ofadditional usable RAM. On an 8086 or an 80x86 with the A20 line disabled,FFFF:0010 "wraps around" and is the same as 0000:0000.
Turning this line on and off is accomplished using the keyboard port andishardware dependent. HIMEM.SYS includes a number of "A20 handlers" fordifferent machines. The XMS allocates and deallocates the HMA as oneblock,that is, only one program can use it at a time. MS-DOS 5.0 and later canrun in the HMA if DOS=HIGH is in the CONFIG.SYS file.
DOS=HIGH Asks MS-DOS to Run in the HMA
If DOS=LOW or no DOS= command is in the CONFIG.SYS file, MS-DOS and itsdata are initialized and loaded into their final place in low memorybeforethe DEVICE= and DEVICEHIGH= commands are processed.
If the DOS=HIGH command is in the CONFIG.SYS file, MS-DOS data (which mustremain low for compatibility) is loaded into its final place inconventional memory. After each device driver is initialized, a check ismade to determine if an XMS driver has been installed. If so, and if theHMA is available, MS-DOS is moved into the HMA. If not, MS-DOS keepschecking after each DEVICE[HIGH]= command, and then begins processing theINSTALL= commands.
If a DOS=HIGH command exists but MS-DOS hasn't loaded high (if no XMSdriver was loaded or the HMA wasn't available), MS-DOS reports "HMA notavailable/loading DOS low" and loads itself into conventional memory aboveall the installable device drivers and/or terminate-and-stay-resident(TSR)programs loaded with INSTALL=.
The transient portion of COMMAND.COM remains in conventional memorywhetherMS-DOS is loaded high or low. Most of the COMMAND.COM resident portion,anysoftware code pages, and the disk buffers (usually) also load high ifDOS=HIGH is in the CONFIG.SYS file.
EMM386.EXE [RAM | NOEMS] Uses XMS to Create EMS and/or UMBs
EMM386.EXE is a device driver for 80386 and higher systems with XMSmemory.EMM386.EXE uses XMS memory to create and manage EMS memory and/or XMSuppermemory blocks (UMBs). EMS is available to programs through the EMS 4.0interface; UMBs are available through the XMS interface. When providingUMBs, EMM386.EXE answers only requests to allocate or deallocate UMBs; allother XMS memory is managed by HIMEM.SYS.
On loading, EMM386.EXE shows a report of its activity. Among other things,this report includes:
- Whether EMS memory is being provided, and, if so:
- Amount of EMS available
- Address of EMS page frame segment
- If UMBs are being provided, the following is also shown:
- Amount of UMBs available through the XMS
- Largest UMB available through the XMS
- Address of upper memory starting segment
This report is also available at the MS-DOS command prompt by runningEMM386.EXE.
NOTE: EMM386.EXE versions 4.45 and later do not display this informationatstartup UNLESS the /VERBOSE switch is used.
DOS=UMB Asks MS-DOS to Manage UMBs
The DOS=UMB command asks MS-DOS to allocate any UMBs available through theXMS to itself. MS-DOS then makes UMBs available through its own memory-management services in Interrupt 21h, including:
Function Description Version ------------------------------------------------------- 48h Allocate memory 2.0 49h Free allocated memory 2.0 4Ah Set memory block size 2.0 5800h Get allocation strategy 2.0 5801h Set allocation strategy 2.0 5802h Get upper-memory link status 5.0 5803h Set upper-memory link status 5.0
If DOS=UMB is in the CONFIG.SYS file, EMM386.EXE reports that 0 (zero)UMBsare available from the MS-DOS command prompt, and any program thatattemptsto use UMBs through the XMS services is unable to find them.
Users can determine whether MS-DOS has any UMBs available by using the MEM/C command. Programs can use Interrupt 21h, Function 5803h to determine ifUMBs exist.
The DEVICEHIGH= command asks that the device driver file be loaded into anMS-DOS UMB if there is one available that is big enough. If there isn't,the driver is loaded into conventional memory and executed; no error isdisplayed by MS-DOS.
The LH (or LOADHIGH) command tells MS-DOS to load the program file into anMS-DOS UMB if there is one available that is big enough. If there is not,the program is loaded into conventional memory and executed; no error isdisplayed by MS-DOS.
DEVICEHIGH AND LOADHIGH WITH /L: AND /S
If you are using MS-DOS version 6.0, 6.2, 6.21, or 6.22, you can use the/Land /S switches to control the memory regions into which a device driverorprogram is loaded.
DEVICEHIGH [[/L:region1[,minsize1][;region2[,minssize2] [/S]]=
The /L: switch specifies the memory region(s) a program can be loadedinto.If the /L: switch is not specified, MS-DOS loads the program into thelargest free UMB and all other UMB regions are available to the program.Use the MEM /F command to view the available memory regions. (Region 0 isconventional memory.)
The /S switch shrinks the UMB to the minimum size (minsize) while theprogram is loading. This switch can only be used in conjunction with the/L: switch and affects only UMBs for which a minimum size was specified.
The following is an example:
LOADHIGH /L:1,12194;2,34213 /S C:\PROGDIR\PROGRAM.EXE
This command loads PROGRAM.EXE and restricts it to load into memoryregions1 and 2. The program has access to only 12,194 bytes in region 1 and only34,213 bytes in region 2.
NOTE: Rather than attempting to manually configure the memory regionsprograms load into, MS-DOS 6.0, 6.2, 6.21, and 6.22 users are encouragedtorun the MemMaker memory optimization program. To run MemMaker, typememmaker
at the MS-DOS command prompt.
MEM Reports on Memory MS-DOS Is Managing
If MS-DOS is managing UMBs (DOS=UMB), MEM /C or MEM /D includes the UMA inits report. Any areas not being managed by MS-DOS are labeled "SYSTEM" inthis report. For UMB information, type mem /c | more
at the MS-DOS command prompt. (Note that if you are using MS-DOS6.0or later, you can type mem /c /p
to view the memory report one screen ata time.)
If MS-DOS is not managing the UMBs, MEM does not report on the UMA. OtherUMB managers typically have some means to determine what is loading high.Check the documentation for your UMB manager for details.
MEM also includes information about extended memory (determined using theInterrupt 15/VDisk header interface), the XMS (reported through the XMS2.0or 3.0 interface), and the EMS (reported through the EMS 3.2 or 4.0interface) for your convenience.
How MS-DOS Uses Extended or Expanded Memory
As a whole, MS-DOS does not use extended or expanded memory for generalusage or for loading applications.
However, some MS-DOS utilities and drivers use extended or expanded memoryfor data areas. In addition, MS-DOS versions 5.0 and later load most oftheMS-DOS kernel, command interpreter, code pages (if used), and disk buffersinto the HMA, which is the first 64K of extended memory.
The table below outlines which MS-DOS utilities use extended memorywithoutan extended memory driver, extended memory through an XMS driver, orexpanded memory through a Lotus-Intel-Microsoft (LIM) EMS driver.
These utilities load into conventional memory but use nonconventionalmemory for data areas. Because different versions of many utilities thatship with MS-DOS also ship with Microsoft Windows, the Windows versionsareincluded in this table. Microsoft recommends that you do not mix versionsof these drivers that are included with different products.
Non-XMS Conv. Extended XMS LIM 3.2/4.0 EMS ------------------------------------------ RAMDRIVE.SYS 3.3 Yes Yes No Yes RAMDRIVE.SYS 4.x Yes Yes No Yes RAMDRIVE.SYS Win30 Yes No Yes Yes RAMDRIVE.SYS 5.x Yes No Yes Yes RAMDRIVE.SYS Win31 Yes No Yes Yes RAMDRIVE.SYS 6.0-6.22 Yes No Yes Yes SMARTDRV.SYS 4.x No Yes No Yes SMARTDRV.SYS Win30 No No Yes Yes SMARTDRV.SYS 5.x No No Yes Yes SMARTDRV.EXE All No No Yes No HIMEM.SYS (1) All No Yes Provider No EMM386.SYS(2) 4.x No Yes No Provider EMM386.SYS(3) Win30 No No Yes Provider EMM386.EXE(3) All No No Yes(4) Provider (1) Uses extended memory to provide XMS memory (2) Uses extended memory to provide EMS memory (3) Uses XMS memory to emulate EMS memory (4) MS-DOS 5.0 and later EMM386.EXE can also be configured to provide UMBs according to the XMS. This causes EMM386.EXE to be a provider of the UMB portion of the XMS.
In MS-DOS versions 4.x, you can place the disk buffers in expanded memoryby using the /X switch; however, this is not recommended because ofproblems that may arise. SMARTDRV can provide much of the same performanceenhancements and is preferable to using BUFFERS /X. For more informationabout BUFFERS /X, query in the Microsoft Knowledge Base on the followingwords:
buffers and ems and /x
Loading the disk buffers in EMS memory is not supported in MS-DOS versions5.0 and later. These versions support loading the MS-DOS kernel and, ifthere is room, the disk buffers into the HMA. MS-DOS accesses the HMAthrough the XMS protocol.
The official LIM EMS specification, "Lotus/Intel/Microsoft Expanded MemorySpecification Version 4.0," is available from Intel by calling (800) 538-3373.
The official XMS specification, "Extended Memory Specification Version3.0," is available free from Microsoft. To obtain the specification, seethe "Instructions for Downloading" section below.
The official MS-DOS program interface documentation, "Microsoft MS-DOSProgrammer's Reference," is available from Microsoft Press (by calling 677-7377), or internationally through Penguin Books.