So far, I've been discussing how Windows manages memory in simple 640-KB systems. Windows also supports bank-switched memory that follows the Lotus-Intel-Microsoft Expanded Memory Specification 4.0 (LIM EMS 4.0).
In a bank-switched memory scheme such as EMS, special memory boards provide multiple banks of memory that can occupy a single same address space. Only one of these multiple banks occupies the address space at any time. By manipulating registers on the memory board, the EMS device driver can switch out one bank of memory and switch in another bank.
Expanded memory under EMS 4.0 is supported in Windows 3 in two configurations:
In the first configuration (called ”small frame“), the bank-switched memory resides in an unused area above the 640-KB level of conventional memory and below the 1-MB level addressable by the 8086 family running in real mode. This 384-KB area contains the ROM BIOS, some BIOS device drivers, and video adapter buffers, but at least 64 KB are usually available for expanded memory.
In the second configuration (called ”large frame“), the bank-switched memory also occupies an area of the 640-KB address space containing conventional memory. The bank-switched memory can usually occupy as much as 384 KB of conventional memory, from the 256-KB level to the 640-KB level. The level above which memory is bank-switched is called the ”bankline.“
The GetWinFlags function includes the flags WF_SMALLFRAME and WF_LARGEFRAME if you need to determine the configuration under which your program is running.
Windows 3 uses bank-switched memory on a per process basis. When switching between Windows programs (which normally occurs during calls to the GetMessage, PeekMessage, and WaitMessage functions), Windows 3 will switch out the banks of memory associated with the first process and switch in the banks of memory associated with the second process.
The chapter entitled ”More Memory Management“ in the Windows Guide to Programming discusses which memory objects are stored below the bankline and above the bankline in the small-frame and large-frame configurations. Generally, this is transparent to the Windows application. The only problem arises when two Windows programs share memory using a technique other than the clipboard, dynamic data exchange, or dynamic link libraries. Such sharing is not recommended because it may not work in future versions of Windows.