zuimeng
初级用户
积分 170
发帖 83
注册 2007-11-30
状态 离线
|
『楼 主』:
[分享]DOS系统中的内存管理
此文是本人在去年配置DOS/Win3.x的内存时，在网上搜集，学习并整理的资料。
也曾在去年发在论坛里，但没有几天就论坛数据库出问题，应该是被回档了，有几天的论坛贴子丢失。
在整理文件时，看到了，就再发上来。
http://zuimeng.vicp.net/topic.asp?TOPIC_ID=1409
1M内存的来由：
IBM推出的第一台PC机采用的CPU是8088芯片，它只有20根地址线，也就是说，它的地址空间是1MB。
PC机的设计师将1MB中的低端640KB用作RAM，供DOS及应用程序使用，高端的384KB则保留给ROM、视频适配卡等系统使用。从此，这个界限便被确定了下来并且沿用至今。
0~640K：用作RAM(随机存储器)。
641K~1M(384K)：保留给ROM(只读存储器)或用作缓冲。在这384K的空间里再依次划分为128K/192K/64K三个内存空间，其中128K为显示缓冲区，64K为系统BIOS空间，最后的192K为保留用，为空。
*********************************************************************************
后面随着程序增大，内存占用增加，以及能访问更大内存空间的新型CPU出现，1M的空间变得局限性了。到80286普遍接受不久，发现640K的限制成为大型程序的障碍。286有24位地址线，可以寻址16M的内存空间，内存地址空间已超过在8088时的1MB的限制。(80386有32位地址线，可以寻址4G的内存空间。)
就出现一个叫扩充内存(EMS:Expanded Memory)，使程序能存取640K以上的内存空间。扩充内存是一种早期的增加内存的标准，最多可扩充到32M。使用扩充内存必须在计算机中安装专门的扩充内存板，而且还要安装管理扩充内存板的管理程序。
由于扩充内存的I/O插槽的地址线只有24位寻址16M空间(286的地址线位)，与后面出的80386的32位寻址4G空间是不能适应的，为了区别扩充内存，把1M以上的地址空间为扩展内存(XMS:eXtend Memory)
在386以上档次的微机中，有两种存储器工作方式，一种称为实地址方式或实方式，另一种称为保护方式。在实方式下，物理地址仍使用20位，所以最大寻址空间还是为1MB，以便与8086兼容。保护方式采用32位物理地址，寻址范围可达4GB。DOS系统在实方式下工作，它管理的内存空间仍为1MB，因此它不能直接使用扩展存储器。
扩充内存和扩展内存的区别并不在于其物理存储器的位置，而在于使用什么方法来读写它。
由于扩充内存是在扩展内存之前推出的，所以大多数程序都被设计成能使用扩充内存，而不能使用扩展内存。但为了程序的兼容，所以在扩展内存中模拟扩充内存给程序使用(这也是在dos为什么先要加载himem.sys后才是emm386.exe)。由于扩充内存使用起来比较麻烦，所以在扩展内存出现后不久，主板上的扩充内存就被淘汰了。
Himem.sys就是管理扩展内存的驱动程序
符合EMS(扩充内存)的驱动程序很多，常用的有EMM386.EXE、QEMM、TurboEMS、386MAX等。DOS和Windows中都提供了EMM386.EXE。
内存空间中第1M地址中划分为：前640K为常规内存(Conventional Memory)和后384K的高端内存(Upper Memory)，这384K也称为保留区(见上面的1M内存来由)。
保留区自从PC诞生之初就明确是保留给系统使用的，用户程序无法插足。为了充分利用这一区域的内存地址空间，就划分了一块内存出来，并命名为UMB(Upper Memory Blocks)，中文里叫上位内存或上们内存块，并由EMS(扩充内存)驱动程序来管理。(个人瞎猜：这就是DOS中为什么有XMS后EMS不灭的原因之一吧，还有兼容。)
从上面的1M内存来由中，可以看出UMB的最大为192KB，但是可通过EMS驱动程序(device=emm386.exe ram=xxxx-xxxx)来调整UMB的大小。说完UMB，再来说说HIGH。
内存空间中超过1M的地址空间，均为XMS管理区域了，但是在1MB后的第一个64K的空间，被划去来命名为高端内存区HMA（High Memory Area）。HMA的物理存储器是由扩展存储器取得的。因此要使用HMA，必须要有物理的扩展存储器存在。此外HMA的建立和使用还需要XMS驱动程序HIMEM.SYS的支持，因此只有装入了HIMEM.SYS之后才能使用HMA。
为什么有这个HMA？？因为在实方式下，内存单元的地址可记为：
段地址：段内偏移
通常用十六进制写为XXXX：XXXX。实际的物理地址由段地址左移4位再和段内偏移相加而成。若地址各位均为1时，即为FFFF：FFFF。其实际物理地址为：FFF0＋FFFF=10FFEF，约为1088KB（少16字节），这已超过1MB范围进入扩展内存的区域了。
*********************************************************************************
从上面看出，HIMEM.SYS是对XMS的空间进行管理，而EMM386.EXE是对EMS的空间进行管理。但是EMS和XMS在1MB以上的内存空间区域管理是重复，而XMS比EMS区域要大，所有一般都不使用EMM386.exe来管理1MB以上的内存空间的那块区域。但EMM386.exe可以对UMB进行管理与利用，所以一般在config.sys使用device=emm386.exe noems(提供对上端内存区的访问，但阻止对扩展内存的访问。)或者干脆就没有加载emm386.exe程序，UMB的空间也不大嘛。
DOS只能直接使用640K的内存(DOS的应用程序只能在常规内存下运行)，即基本内存（或常规内存），必须依靠其它内存管理程序来使用更多的内存。DOS系统内置himem.sys和emm386.exe两条命令就是最常用的内存管理程序。
640K到1M之间的内存是系统保留区，保留区内有上位内存(UMB)空间。
1M以上的内存空间叫扩展内存XMS（或者说扩充内存EMS）；
himem.sys负责管理扩展内存(XMS)。
emm386.exe负责管上位内存(UMB)，并在扩展内存(XMS)中模拟扩充内存(EMS)供某些软件使用。
#在XMS中虚拟16M的EMS。
device=emm386 ram 16000
注意：EMM386.exe要求先安装himem.sys，因而必须确保安装himem.sys的配置命令在emm386.exe之前。
保留区内存是指位于常规内存之上的384K内存。程序一般不能使用这个内存区域，但是EMM386.exe可以激活保留区内存的一部分，并且它允许用户将某些设备驱动程序和用户程序用Devicehigh或LH(即loadhigh)装入高端内存。dos=high,umb也是把DOS的一部分装到高端内存里。这里的umb是高端内存块(Upper Memory Block)的缩写。
在config.sys中加入dos=high,umb，这样会将DOS的系统文件移入高端内存，空出更多的基本内存给其它软件使用。 注意，如果用户没有安装emm386.exe，umb这个参数是没有实际意义的。 同样，如果没有安装himem.sys，high这个参数也没有实际意义。
DOS ：用于DOS系统的配置，如是否使用HMA（高端内存区）和UMB（上位内存）等。
用法：DOS=[HIGH|LOW][,UMB|,NOUMB]
含意：HIGH和LOW表示使用HMA或不使用HMA，UMB和NOUMB表示使用UMB或不使用UMB。
*********************************************************************************
基本内存：也称常规内存，0~640K
保留区内存：641K~1MB(384K)，包含上位内存（UMB），可以使用emm386.exe来使用UMB区域。
上位内存：UMB，在高端内存中一个TSR、辅助驱动程序的区域
HMA高端内存：1M后的第一个64K的高端内存(HMA，himem.sys由管理)
XMS扩展内存：1M后的内存空间区域。
EMS扩充内存：1M后的内存空间区域，先于xms出现。
有时把保留区内存也叫高端内存。
http://zuimeng.vicp.net/Attachment/dosmemjg.jpg
此图见附件
常规内存(640K)中的区域划分：
1.中断向量区：地址范围为00-3FFH，占1KB，又称中断向量表区。
2.BIOS数据区：范围为400～4FFH，占256个字节，供特殊程序BIOS存放数据。
3.系统数据区：地址范围为500～6FFH，占512个字节，用于操作系统存放信
息的小区域，存储在计算机启动时存放初始化信息。
4.应用内存区：范围为700～9FFFH，占638KB，通常用来运行程序的内存区。
*********************************************************************************
在DOS里有一个很好工具：MemMaker，可以帮你释放出更多的基本内存(640K)。
在config.sys中可以使用DEVICEHIGH命令把驱动加载到UMB里，在autoexec.bat里可以使用LH命令把驱动加载到UMB里。
MS KB: Overview of Memory-Management Functionality in MS-DOS (MS-DOS内存管理的概述)
http://support.microsoft.com/kb/95555/en-us
*********************************************************************************
SUMMARY
This article contains an overview of how expanded memory that conforms to the Expanded Memory Specification (EMS) and extended memory that conforms to the Extended Memory Specification (XMS) is created and managed in MS- DOS versions 5.0 and later by the device drivers HIMEM.SYS and EMM386.EXE. How MS-DOS is loaded into the high memory area (HMA) and manages upper memory blocks (UMBs) are also discussed.
NOTE: Before reading this article, you may want to review the sections about memory management, HIMEM.SYS, and EMM386.EXE in your printed MS-DOS documentation. If you are using MS-DOS 6.0, 6.2, 6.21, or 6.22, refer to the online help. For example, type help emm386.exe at the MS-DOS command prompt.
Information in this article is organized as follows:
·Old Extended Memory Allocation Methods: Interrupt 15h and VDisk Headers
·HIMEM.SYS Creates XMS Memory
·A20 and the HMA
·DOS=HIGH Asks MS-DOS to Run in the HMA
·EMM386.EXE [RAM | NOEMS] Uses XMS to Create EMS and/or UMBs
·DOS=UMB Asks MS-DOS to Manage UMBs
·DEVICEHIGH=[<drive>:][\<path>\]<filename>
·LH (LOADHIGH)
·DEVICEHIGH AND LOADHIGH WITH /L: AND /S
·MEM Reports on Memory MS-DOS Is Managing
·How MS-DOS Uses Extended or Expanded Memory
·Available References
NOTE: Only the section "How MS-DOS Uses Extended or Expanded Memory" applies to MS-DOS versions 3.x and 4.x.
MORE INFORMATION
Old Extended-Memory Allocation Methods: Interrupt 15h & VDisk Headers
In the past,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 to the original PC ROM BIOS, including the means to find out how much RAM (conventional plus extended) is on the system. A program uses this service to find out how much extended memory there is, then "hooks" Interrupt 15h and reports to any other programs that there is <n>K less memory available, effectively slicing <n>K of extended memory off the top. By doing this, the program has allocated its own extended memory from the top of the memory pool.
Bottom-up memory allocation works by checking for a header at the start of extended 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 headers because the original IBM DOS RAM drive utility (VDISK.SYS) uses this method.
A drawback to these methods is that after memory has been allocated to a program, deallocating it is usually not possible. The XMS was designed to make 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 up to 16 MB of RAM; versions 3.0 and later (first included with Windows 3.10 and 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 to allocate all available extended memory for use as XMS memory (note the actual allocation of all the available extended memory does not occur until a program makes an XMS function call). HIMEM.SYS reserves the HMA with a VDisk header and hooks Interrupt 15h. Programs that want to use extended memory (other than the HMA) without using XMS can do so until a program actually requests XMS.
After a program actually asks for XMS memory, HIMEM.SYS uses its Interrupt 15h hook to notify programs that only the amount of extended memory specified by /INT15=xxxx, minus the HMA (64K), is available for use. Memory available 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 that have physical addressable RAM at these addresses. This area can be addressed in real mode (8086 emulation) on 80286 and higher systems if the 21st address line (A20) is enabled, which produces 64K-16 bytes of additional 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 and is hardware dependent. HIMEM.SYS includes a number of "A20 handlers" for different machines. The XMS allocates and deallocates the HMA as one block, that is, only one program can use it at a time. MS-DOS 5.0 and later can run 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 its data are initialized and loaded into their final place in low memory before the DEVICE= and DEVICEHIGH= commands are processed.
If the DOS=HIGH command is in the CONFIG.SYS file, MS-DOS data (which must remain low for compatibility) is loaded into its final place in conventional memory. After each device driver is initialized, a check is made to determine if an XMS driver has been installed. If so, and if the HMA is available, MS-DOS is moved into the HMA. If not, MS-DOS keeps checking after each DEVICE[HIGH]= command, and then begins processing the INSTALL= commands.
If a DOS=HIGH command exists but MS-DOS hasn't loaded high (if no XMS driver was loaded or the HMA wasn't available), MS-DOS reports "HMA not available/loading DOS low" and loads itself into conventional memory above all the installable device drivers and/or terminate-and-stay-resident (TSR) programs loaded with INSTALL=.
The transient portion of COMMAND.COM remains in conventional memory whether MS-DOS is loaded high or low. Most of the COMMAND.COM resident portion, any software code pages, and the disk buffers (usually) also load high if DOS=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 XMS memory. EMM386.EXE uses XMS memory to create and manage EMS memory and/or XMS upper memory blocks (UMBs). EMS is available to programs through the EMS 4.0 interface; UMBs are available through the XMS interface. When providing UMBs, EMM386.EXE answers only requests to allocate or deallocate UMBs; all other 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 running EMM386.EXE.
NOTE: EMM386.EXE versions 4.45 and later do not display this information at startup 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 the XMS 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) UMBs are available from the MS-DOS command prompt, and any program that attempts to 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 if UMBs exist.
DEVICEHIGH=[<drive>:][\<path>\]<filename>
The DEVICEHIGH= command asks that the device driver file be loaded into an MS-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 is displayed by MS-DOS.
LH (LOADHIGH)
The LH (or LOADHIGH) command tells MS-DOS to load the program file into an MS-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 is displayed 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 /L and /S switches to control the memory regions into which a device driver or program is loaded.
DEVICEHIGH [[/L:region1[,minsize1][;region2[,minssize2] [/S]]=
The /L: switch specifies the memory region(s) a program can be loaded into. If the /L: switch is not specified, MS-DOS loads the program into the largest 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 is conventional memory.)
The /S switch shrinks the UMB to the minimum size (minsize) while the program 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
DEVICEHIGH /L:2,12048 =C:\DOS\SETVER.EXE
This command loads PROGRAM.EXE and restricts it to load into memory regions 1 and 2. The program has access to only 12,194 bytes in region 1 and only 34,213 bytes in region 2.
NOTE: Rather than attempting to manually configure the memory regions programs load into, MS-DOS 6.0, 6.2, 6.21, and 6.22 users are encouraged to run the MemMaker memory optimization program. To run MemMaker, type memmaker 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 in its report. Any areas not being managed by MS-DOS are labeled "SYSTEM" in this report. For UMB information, type mem /c | more at the MS-DOS command prompt. (Note that if you are using MS-DOS 6.0 or later, you can type mem /c /p to view the memory report one screen at a time.)
If MS-DOS is not managing the UMBs, MEM does not report on the UMA. Other UMB 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 the Interrupt 15/VDisk header interface), the XMS (reported through the XMS 2.0 or 3.0 interface), and the EMS (reported through the EMS 3.2 or 4.0 interface) for your convenience.
How MS-DOS Uses Extended or Expanded Memory
As a whole, MS-DOS does not use extended or expanded memory for general usage or for loading applications.
However, some MS-DOS utilities and drivers use extended or expanded memory for data areas. In addition, MS-DOS versions 5.0 and later load most of the MS-DOS kernel, command interpreter, code pages (if used), and disk buffers into the HMA, which is the first 64K of extended memory.
The table below outlines which MS-DOS utilities use extended memory without an extended memory driver, extended memory through an XMS driver, or expanded memory through a Lotus-Intel-Microsoft (LIM) EMS driver.
These utilities load into conventional memory but use nonconventional memory for data areas. Because different versions of many utilities that ship with MS-DOS also ship with Microsoft Windows, the Windows versions are included in this table. Microsoft recommends that you do not mix versions of 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 memory by using the /X switch; however, this is not recommended because of problems that may arise. SMARTDRV can provide much of the same performance enhancements and is preferable to using BUFFERS /X. For more information about BUFFERS /X, query in the Microsoft Knowledge Base on the following words:
buffers and ems and /x
Loading the disk buffers in EMS memory is not supported in MS-DOS versions 5.0 and later. These versions support loading the MS-DOS kernel and, if there is room, the disk buffers into the HMA. MS-DOS accesses the HMA through the XMS protocol.
Available References
The official LIM EMS specification, "Lotus/Intel/Microsoft Expanded Memory Specification Version 4.0," is available from Intel by calling (800) 538- 3373.
The official XMS specification, "Extended Memory Specification Version 3.0," is available free from Microsoft. To obtain the specification, see the "Instructions for Downloading" section below.
The official MS-DOS program interface documentation, "Microsoft MS-DOS Programmer's Reference," is available from Microsoft Press (by calling [800] 677-7377), or internationally through Penguin Books.
--------------------------------------------------------------------------------
APPLIES TO
Microsoft MS-DOS 3.1
Microsoft MS-DOS 3.2 Standard Edition
Microsoft MS-DOS 3.21 Standard Edition
Microsoft MS-DOS 3.3 Standard Edition
Microsoft MS-DOS 3.3a
Microsoft MS-DOS 4.0 Standard Edition
Microsoft MS-DOS 4.01 Standard Edition
Microsoft MS-DOS 5.0 Standard Edition
Microsoft MS-DOS 5.0a
Microsoft MS-DOS 6.0 Standard Edition
Microsoft MS-DOS 6.2 Standard Edition
Microsoft MS-DOS 6.21 Standard Edition
Microsoft MS-DOS 6.22 Standard Edition
附件
1:  DOSMEMJG.PNG (2010-7-31 19:53, 28.8 K,下载次数： 1)
|
|
