INF: EMS Support in Windows Version 3.00 And 3.10

ID Number: Q57954

2.03 2.10 3.00 3.10

WINDOWS

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 a non-Windows application.

4. Making EMS calls from a Windows 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 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 a non-Windows application.

If EMS is present, non-Windows applications 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 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: 2.03 2.10 2.x 3.00 3.10 3.x