EMS Support in Windows Versions 3.0 and 3.1

Last reviewed: July 22, 1997
Article ID: Q57954
3.00 3.10 WINDOWS kbprg

The information in this article applies to:

  • Microsoft Windows Software Development Kit (sdk) for Windows versions 3.0 and 3.1

SUMMARY

The information listed below discusses the following topics:

  1. Windows version 3.x support of EMS.

  2. Utilization of the services of an already-installed LIM EMS (Lotus/Intel/Microsoft Expanded Memory Support) version 4.0 driver, such as a "limulator" or hardware EMS board by Windows version 3.x.

  3. Making EMS calls from an application not based on Windows.

  4. Making EMS calls from a Windows-based application.

MORE INFORMATION

  1. Windows version 3.x support of EMS.

    Windows version 3.x has three modes: real mode, standard mode, and enhanced mode. Of the three, only enhanced mode provides EMS. This is because "limulation" [simulation of LIM (Lotus/Intel/Microsoft)] requires hardware support that only the Intel 80386 provides; the 8086 and 80286 do not have the necessary combination of protected mode addressing and virtual 8086 emulation (provided by the 80386's V86 mode).

  2. Utilization of the services of an already-installed LIM EMS (Lotus/Intel/Microsoft Expanded Memory Support) version 4.0 driver, such as a "limulator" or hardware EMS board by Windows version 3.x.

    Real mode Windows can take advantage of either a limulator or a hardware EMS board.

    Windows version 3.0 standard mode (which runs in 80286 protected mode) cannot use a limulator because these drivers run in 80386 protected mode, thereby conflicting with the standard mode's need to switch into protected mode. However, if the machine has a hardware EMS board and associated LIM version 4.0 driver installed, any EMS calls made will be serviced by the EMS driver; however, Windows itself will not use the EMS memory in any way. Only small frame EMS is supported in protected mode.

    In Windows version 3.1, it is possible to start limulators such as QEMM, 386MAX and EMM386 in standard mode. All support for EMS from protected mode Windows-based applications has been dropped from Windows version 3.1 enhanced mode. Any INT67H calls made by a Windows application in enhanced mode under Windows version 3.1 will result in an error being returned.

    Enhanced mode is incompatible with preinstalled EMS drivers that cannot be "shut off" by Windows. If the EMS driver is a limulator that cannot be shut off, Windows will not be able to run in enhanced mode because the 80386 is already running in protected mode; limulators that can be shut off respond to Windows as it boots, turning themselves off and letting Windows manage the EMS that they had been managing.

    Physical LIM memory is not supported by 386 enhanced mode Windows. Software running in Virtual 8086 mode in any VM (virtual machine), including the system VM (which contains all the Windows applications), can make LIM version 4.0 calls; however, the calls will be handled by Windows/386, not by any previously installed LIM driver. No LIM calls are reflected; they are all handled (error or successful completion) by V86MMGR. As mentioned above, only small frame EMS is supported in protected mode.

  3. Making EMS calls from an application not based on Windows.

    If EMS is present, MS-DOS-based applications and other applications not based on Windows have the full LIM version 4.0 specification available for their use. Running in enhanced mode, part of the mappable page array may not be usable; therefore, applications have to be sensitive to what is usable in the mappable page array and what is not; they cannot assume that all of the mappable page array is available.

  4. Making EMS calls from a Windows-based application.

    If EMS is present, the normal small-frame EMS calls work as they do in Windows version 2.x (that is, applications can make LIM version 3.2 calls plus LIM version 4.0's realloc function). This allows both Windows versions 2.x and 3.x applications to use EMS memory.

    CAUTION: In protected mode, the standard technique of querying for the presence of an EMS driver by examining the contents of interrupt vector 67H will fail due to virtualization of memory and virtualization of the IDT (interrupt description table). Therefore, applications will have to use the alternate technique of opening a file handle using the name of the EMS device driver. For more information on these techniques, please consult Chapter 9 of Ray Duncan's "Advanced MS-DOS" book (Microsoft Press, 1986), which is the chapter on memory management under MS-DOS. This chapter contains a discussion on EMS that describes how to check for the presence of an EMS driver.

    Windows version 3.x applications that use EMS when running in protected mode will be slower than non-EMS-using applications, and may run out of memory faster. If it is necessary to run a Windows version 2.x application that requires EMS under Windows version 3.x, this can easily be done in enhanced mode. When designing a new application for Windows version 3.x, however, the programmer should take advantage of the new protected mode addressing scheme rather than trying to use EMS.

    CAUTION: In protected mode, the value returned as the location of the page frame is a selector, not a segment. Therefore, applications cannot make any assumptions about that value. Many EMS-using applications, besides encountering the inefficiency of using EMS, will probably run into other restrictions that will not allow them to run in protected mode. For example, they cannot put code into EMS unless they implement special handling in protected mode to create a code selector alias for the page frame selector.

    For enhanced mode, there are SYSTEM.INI entries that correspond to the same entries in the .PIF file. The Control Panel does not touch them. We do not expect many programmers to need to do anything with these at all. See the PIFEDIT documentation for information on the meanings of possible values.

    Example:

    ; The following variables perform the equivalent of the XMS and ; EMS memory PIF settings for the SYS VM: ;

       SYSVMEMSLIMIT           Max value (default is -1)
       SYSVMEMSREQUIRED        Min value (default is -1)
       SYSVMEMSLOCKED          Is the EMS touched under interrupt or needed
                               to be in memory at all times for some other
                               reason? (default is NO)
       SYSVMXMSLIMIT           Max value (default is -1)
       SYSVMXMSREQUIRED        Min value (default is -1)
       SYSVMXMSLOCKED          Is the EMS touched under interrupt or needed
                               to be in memory at all times for some other
                               reason? (default is NO)
    
       Related switch:
    
       EMMSIZE                 Controls the maximum amount of memory
                               that will be used for EMS across all
                               VMs (default is -1, no limit).
    


Additional reference words: 3.00 3.10
KBCategory: kbprg
KBSubcategory: KrIsrTsr
Keywords : kb16bitonly


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: July 22, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.