Xref: utzoo comp.sys.ibm.pc.misc:8339 comp.os.msdos.apps:1589 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!mahendo!wlbr!news From: mcc@wlv.imsd.contel.com (Merton Campbell Crockett) Newsgroups: comp.sys.ibm.pc.misc,comp.os.msdos.apps Subject: Extended/Expanded Memory Question Keywords: Extended memory, expanded memory, memory management Message-ID: <1991Apr6.194510.4445@wlbr.imsd.contel.com> Date: 6 Apr 91 19:45:10 GMT Sender: news@wlbr.imsd.contel.com (news) Organization: Contel Federal Systems Lines: 102 Nntp-Posting-Host: wlv.imsd.contel.com 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.