EMS Support in Windows Versions 3.0 and 3.1
ID: Q57954
|
The information in this article applies to:
-
Microsoft Windows Software Development Kit (SDK) versions 3.0, 3.1
SUMMARY
The information listed below discusses the following topics:
- Windows version 3.x support of EMS.
- 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.
- Making EMS calls from an application not based on Windows.
- Making EMS calls from a Windows-based application.
MORE INFORMATION- 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).
- 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.
- 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.
- 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 query words:
3.00 no32bit 3.10
Keywords : kb16bitonly
Version : WINDOWS:3.0,3.1
Platform : WINDOWS
Issue type :
|