				AXCEL216's MAX Speeed
		WINDOWS 3.xx + WFWG 3.1x VIRTUAL MEMORY MANAGEMENT




NOTES:	* Windows 386 ENHANCED MODE applies ONLY to Windows 3.xx and Windows
	for WorkGroups 3.1x, NOT to Windows 95/98/NT/2000/ME/XP!
	* For memory management guide + optimization tips *READ* MEMORY.TXT
	(included).
	* For abbreviations + terms explanations see GLOSSARY.TXT (included).
	* For DOS + Windows extended + expanded memory managers technical
	details see EMM386.TXT (included).
	* For DOS memory types, architecture + mapping technical details see
	REGIONS.TXT (included).
	* For Microsoft EMM386.EXE + HIMEM.SYS undocumented parameters see
	related topics in SECRETS.TXT (included).

CREDITS: Most of this information is found at MicroSoft Knowledge Base (MSKB):
	 http://support.microsoft.com/


WIN31MEM.TXT Contents:


WINDOWS 386 ENHANCED MODE VIRTUAL MEMORY MANAGEMENT
WIN.COM AUTOMATIC STARTUP PARAMETERS
THE FREE SYSTEM RESOURCES PERCENTAGE
386 ENHANCED MODE PERFORMANCE TIPS: GETTING THE MOST FROM YOUR MACHINE
EXPANDED MEMORY FOR MS-DOS APPLICATIONS
______________________________________________________________________________



WINDOWS 386 ENHANCED MODE VIRTUAL MEMORY MANAGEMENT



386 Enhanced Mode and Conventional Memory


Windows 386 enhanced mode deals with conventional memory in much the same way
that standard mode does. When 386 enhanced mode Windows 3.1x is started, it
adds the amount of free conventional and extended memory; in addition, Windows
3.1x can use hard disk space as virtual memory (the "swap" file) and look at
the total amount as one contiguous block of memory. Conventional memory has no
special meaning under 386 enhanced mode, except when running MS-DOS
applications. In 386 enhanced mode, MS-DOS applications run by creating
Virtual MS-DOS Machines (VMs) with up to 640 KB of free memory. Each VM
inherits the environment that was present before Windows 386 enhanced mode was
started. This means that every driver and TSR program loaded before you run
Windows, as well as the environment, is present and consumes memory in every
subsequent VM. The net memory available within VMs under 386 enhanced mode is
slightly less than the free memory at the MS-DOS prompt before you start
Windows, due to the overhead of creating and managing a VM.


386 Enhanced Mode and the 384K Upper Memory Area (UMA)


Windows 386 enhanced mode uses the 384K UMA for 2 purposes:
1. To place MS-DOS protected mode application programming interface (API)
   translation buffers.
2. To place the LIM 3.2 expanded memory page frame (if required). As noted
   earlier, there may be adapters, such as network cards, trying to use the
   384K UMA as well. Frequently, all the free pages in this area are used by
   386 enhanced mode.


API Translation Buffers in the 384K Upper Memory Area (UMA)


Although Windows 3.1x 386 enhanced mode breaks the 640K barrier for Windows
applications, it still runs on top of MS-DOS. The copy of MS-DOS upon which
Windows is running can execute and access data only within conventional
memory.
The same restriction applies to network software or other drivers loaded
before 386 enhanced mode Windows. 386 enhanced mode allocates buffers in the
384K UMA to translate MS-DOS and network API calls from protected mode to real
mode. Since the 384K UMA is within the first megabyte of address space, it can
be accessed by MS-DOS in real mode. The translation buffers are used as a
window through which applications running in protected mode can pass
information to and from MS-DOS and the network drivers.
Ideally, there would be enough free space in the 384K UMA to place both the
translation buffers and the expanded memory page frame. Yet on many
configurations there isn't enough room, and on those systems you have to make
a choice. Either the expanded memory page frame can be eliminated, or the
translation buffers can be allocated in conventional memory instead of in the
384K UMA. If the translation buffers are allocated in conventional memory,
they take up space in every Virtual Machine that you create from Windows, and
you will have less space in which to run MS-DOS applications. The translation
buffers can be allocated either in the 384K UMA or in conventional memory, but
never half and half.
Fortunately, Windows 386 enhanced mode provides a method for specifying your
preference. Place the following setting in SYSTEM.INI [386enh] section:
ReservePageFrame=boolean
If ReservePageFrame=true (the default), 386 enhanced mode Windows allocates
the page frame first and the translation buffers second.
This makes it likely that the translation buffers will be forced into
conventional memory, but allows you to use expanded memory in MS-DOS
applications. If ReservePageFrame=false, the translation buffers are allocated
first and the page frame second if there is still room.
ReservePageFrame=false provides the most free memory within Virtual Machines,
although some MS-DOS applications may not be able to use expanded memory
(EMS).
However, Windows applications do NOT need expanded memory to function; only
MS-DOS applications that can use EMS will be affected.
If using EMM386.EXE translation buffers are always placed in conventional
memory (up to MS-DOS 6.22) if not using a 3rd party memory manager like
DOSMAX, QEMM, NetRoom, 386MAX etc.


Page Frame Placement in the 384K Upper Memory Area (UMA)


As noted in the expanded memory discussion earlier, expanded memory support
requires a page frame located in the 384K UMA. With LIM 4.0 expanded memory,
it is not necessary to have a 64K contiguous page frame in this area.
In fact, it's not necessary to have a page frame at all in LIM 4.0. Still, if
you want to use expanded memory in your MS-DOS applications, you must have a
64K contiguous page frame (composed of 4 contiguous 16K pages in the 384K UMA)
because most applications are written to take advantage of LIM 3.2 expanded
memory.
On a typical IBM compatible machine there are only 12 free 16K pages in the
384K UMA. 4 contiguous pages are required for expanded memory support in
MS-DOS applications, leaving only 8 other free pages. Other items such as
network adapters and hard disk controllers, also need to occupy pages in the
384K UMA. Frequently, the combination of installed adapters can break up the
free area in the 384K UMA so there is no 64K contiguous area in which to place
the page frame. In this case, you will not see any free expanded memory in
your MS-DOS applications.
If you experience this problem, you may need to rearrange your adapter memory
locations to get expanded memory support for MS-DOS applications.
Normal Industry Standard Architecture (ISA) bus machines may require you to
open the case and flip DIP switches or move jumpers on the cards to change
memory addresses; check your hardware manual for more info on changing memory
addresses. You can entirely disable expanded memory support under Windows 386
enhanced mode by adding the NoEMMDriver=yes setting in SYSTEM.INI, under the
[386enh] section.


Controlling 386 Enhanced Mode 384K Upper Memory Area (UMA) Mapping


The SYSTEM.INI [386enh] settings EMMExclude= and EMMInclude= are used under
Windows 386 enhanced mode to control the expanded memory page frame placement
and the API translation buffer mapping. Under Windows 3.1x these settings
begin with the letters "EMM" only for compatibility reasons; they no longer
apply only to expanded memory. The EMMPageFrame= setting, however, still
applies only to the expanded memory page frame. Windows 386 enhanced mode uses
this segment unless the machine identifies itself as a PS/2.
To explicitly exclude an area of the 384K UMA from mapping by Windows 386
enhanced mode, use the EMMExclude=xxxx-yyyy setting. The EMMExclude= setting
accepts a 4-digit hexadecimal memory range, such as EMMExclude=E000-EFFF.
Since there is no standard for hardware implementation of the E000-EFFF area,
it is frequently necessary to exclude this range in order for 386 enhanced
mode to function properly. Most adapter cards are automatically detected and
excluded by Windows 386 enhanced mode. If you suspect a problem with a 384K
UMA memory conflict, use the EMMExclude= setting.
If you suspect your machine has multiple adapter mapping conflicts, it may be
useful to exclude the entire UMA (A000-EFFF) for testing purposes:
EMMExclude=A000-EFFF
There are very few uses for the EMMInclude= setting. Normally Windows 3.1x 386
enhanced mode automatically uses all free pages in the 384K UMA.
Likewise, there are few uses for the EMMPageFrame= setting because it controls
only the expanded memory page frame, not the translation buffers.


386 Enhanced Mode and Expanded Memory


Windows 386 enhanced mode does not use expanded memory itself. It can,
however, create expanded memory for use by MS-DOS applications written to use
expanded memory. See "BASIC *ESSENTIAL* MEMORY TIPS" in MEMORY.TXT (included)
for a list of such programs.
Expanded memory required by an MS-DOS application can be specified in the
application's Program Information File (PIF). It is not necessary for Windows
applications to use expanded memory because they can access extended memory
directly.
Thus, the main issues for expanded memory under Windows 3.1x are page frame
conflicts, as discussed above.
Windows 386 enhanced mode provides large page frame LIM 4.0 expanded memory in
all Virtual MS-DOS Machines. Although this feature is not currently useful for
most MS-DOS applications that use expanded memory, they use only the LIM 3.2
64K page frame itself, not the additional bankable pages in conventional
memory that large page frame LIM 4.0 supplies, it may be useful in the future.
A compatible external 386 memory manager such as EMM386.EXE can be loaded to
provide expanded memory for MS-DOS applications running outside Windows 386
enhanced mode. Such a memory manager is not needed for expanded memory to be
available inside Windows 3.1x, and is actually turned off when Windows 386
enhanced mode is run.


386 Enhanced Mode and Extended Memory


Windows 386 enhanced mode can directly access extended memory (XMS). It adds
free conventional memory and free extended memory plus virtual hard drive
memory (the "swap" file). It then provides the total as memory for Windows
applications to use (minus the memory required by 386 enhanced mode Windows
itself). MS-DOS applications that use extended memory can also access extended
memory in Virtual Machines under 386 enhanced mode Windows. The extended
memory supplied to MS-DOS applications by Windows 3.1x 386 enhanced mode can
be virtualized.


Running Protected Mode MS-DOS Applications


Windows 386 enhanced mode allows MS-DOS applications to run in protected mode
if they are written to use the DPMI specification. Windows 386 enhanced mode
uses the XMS driver to load itself and its drivers into extended memory before
starting up. This is why 386 enhanced mode requires the presence of HIMEM.SYS
or another compatible XMS device driver.


386 Enhanced Mode and Virtual Memory: A Virtual Memory Conceptual Analysis


Virtual memory allows you to simultaneously run more programs than the amount
of physical memory installed on your computer would normally allow. Virtual
memory has been widely used for years in the world of mainframe computers.
Windows 386 enhanced mode offers virtual memory to the PC-compatible world by
using the special demand paging capabilities of the Intel 80386 processor.
All Windows programs can take advantage of virtual memory in Windows 386
enhanced mode. When you start Windows 386 enhanced mode, choose About Program
Manager from the Help menu. You will see that much more memory is available
than is installed on your machine. Windows applications can use this extra
memory without being written specially for it because Windows applications are
device independent; they let Windows handle the memory management and simply
ask Windows for memory allocations. With virtual memory, Windows applications
keep asking for more memory, which Windows 386 enhanced mode is now able to
deliver.
If you have less physical memory and are forced to rely on virtual memory, the
application runs more slowly; if you have more physical memory, it runs more
quickly, in either case, it is almost always able to run.
While a program is running in virtual memory, at any given moment some parts
of its code and data are in physical memory while the rest of the program is
swapped to the hard disk. When a reference is made to a memory address, if the
information is in physical memory, the information is used without program
interruption. However, if the desired information is not in physical memory, a
page fault occurs, and the Windows 386 enhanced mode Virtual Memory Manager
(VMM) takes control.
The required code or data is pulled into physical memory from the hard disk,
and if necessary, some other information is swapped out. Pages are swapped out
on a Least Recently Used (LRU) basis. The pages that have not been accessed
for the longest time are the first to be swapped out.
All this swapping is invisible to the user, who sees only a little hard disk
activity.
Windows 386 enhanced mode virtual memory brings pages of data into physical
memory when they are referenced: this is called a demand-paged system. This
system does not attempt to predict which pages will be required in the future.
The 386 enhanced mode virtual memory subsystem is implemented by the Windows
3.1x VMM and the page swap device. The VMM maintains the virtual memory page
table; it lists which pages are currently in physical memory and which are
swapped to disk. Because Windows 386 enhanced mode is a multitasking
environment, the VMM page table also contains a list of which memory pages
belong to which process. When the VMM needs a page that is not currently in
physical memory, it calls the page swap device. The page swap device allocates
and deallocates virtual memory and maps pages into and out of physical memory.
Some virtual memory systems rely on program segmentation to do their work.
Windows applications are segmented; however, virtual memory under Windows 386
enhanced mode is not related to the segmentation of Windows applications.
All memory, virtual and physical, is divided into 4K pages, and the system is
managed on this basis. Page mapping starts at zero K and works up. 2 kinds of
pages can be allocated: physical pages and virtual pages. The number of
physical pages is simply the amount of physical memory in the machine divided
by 4K. In contrast, memory allocated to an application is made up of virtual
pages. At any given time, a virtual page can be in physical memory or swapped
to the hard disk.
As mentioned earlier, Windows 386 enhanced mode virtual memory management uses
the LRU page-replacement algorithm. The virtual page table contains flags for
each page that indicate whether the page has been "accessed" and if the page
is "dirty." Accessed means that a process made a reference to the page after
it was originally loaded. Dirty means that a write was made to the page after
it was loaded. Because a memory write qualifies as an access, the dirty
attribute implies the accessed attribute.
To illustrate, assume Windows 386 enhanced mode is out of physical memory
space. A process requests additional memory. Windows has to decide which pages
currently in physical memory it should swap to disk to fulfill the request.
This decision is a 3 step process:
1. The VMM scans the page table, looking for pages that have neither an
accessed nor a dirty attribute. During the scanning process, the VMM clears
   the accessed attribute from all the pages.
2. If the VMM can find enough pages meeting the not accessed/not dirty
   requirement, it fulfills the request. It swaps the pages to disk and gives
   the resulting free memory to the process.
3. If the VMM can't find enough pages the first time through, it repeats the
   scan. However, this time through, none of the pages has an accessed
   attribute, because it was cleared by the first scan.
   Theoretically, therefore, more pages will meet the requirements, and the
   request can be fulfilled. If the required pages are still not found by the
   2nd scan, Windows then swaps out the pages regardless of their attributes.
The benefit of Windows 386 enhanced mode virtual memory support is the
ability to run more programs than can be supported by actual physical memory.
The drawbacks are the disk space requirement for the virtual memory swap file
and a decrease in overall execution speed when swapping is required. However,
it's better to be able to run a program slowly in a virtual memory system than
not to be able to run it at all.


Virtual Memory Paging File Options and Controls


Windows 386 enhanced mode can use one of 2 types of virtual memory paging
files, or swap files: temporary or permanent. Only one type of swap file can
be used at a time when running Windows 3.1x. Do not attempt to create a swap
file on a RAM disk; it's a self-defeating pursuit, you would be sacrificing
physical memory to provide a place to create virtual memory to replace the
physical memory you have used to create the RAM disk. Windows 3.1x in 386
enhanced mode requires a minimum of approximately 512KB of hard disk space
free on the paging drive to provide virtual memory support with a temporary
swap file. A temporary swap file is simply a normal MS-DOS file created on the
hard disk that can shrink and grow in size as necessary.
The temporary swap file is called WIN386.SWP, and it is created automatically
when Windows 3.1x is started. The swap file does not have a hidden or system
attribute and can be deleted, if necessary, any time you are not running
Windows, although it is normally deleted automatically when you exit Windows
386 enhanced mode.
Temporary swap file location and size can be adjusted by inserting parameters
in the [386enh] section of the SYSTEM.INI file. In Windows 3.1x, the drive and
subdirectory of the temporary swap file may be specified with the PagingFile=
setting. Temporary swap file size is controlled by the MaxPagingFileSize=
setting. The size of the temporary swap file can also be limited in a
different way by the use of the MinUserDiskSpace= setting, which tells 386
enhanced mode to leave the specified amount of disk space in kilobytes free
when creating a temporary swap file.
A permanent swap file occupies a contiguous section of your hard disk. Using a
permanent swap file improves the speed of the Windows 3.1x virtual memory
system because there are fewer processor mode transitions and the swap file's
access requires less overhead than a normal MS-DOS file. The permanent swap
file is a hidden file called 386SPART.PAR, which also has a system attribute;
the file is always placed in the root directory of the specified drive. Since
the permanent swap file must be contiguous, you can't create one larger than
the largest contiguous free segment of your hard disk. Permanent swap files
are created and deleted from the Windows 3.1x Control Panel by choosing the
386 Enhanced icon and then choosing the Virtual Memory button.
A SYSTEM.INI file setting is not used to point to the location of the
permanent swap file. Instead, when the permanent swap file is created, Windows
creates a file called SPART.PAR in your Windows 3.1x directory.
Windows 386 enhanced mode reads the SPART.PAR file to find out where the
permanent swap file is and how large it is. SPART.PAR is marked read-only to
keep you from accidentally deleting it. If you delete SPART.PAR, Windows will
not know about the permanent swap file and won't be able to make use of it.
Because Virtual Memory utility reads SPART.PAR, it cannot be used to delete
the permanent swap file if SPART.PAR is deleted. If Control Panel says that
the maximum swap file size it can create is smaller than your free disk space,
your hard disk is fragmented.
If you want to create a larger permanent swap file than Control Panel reports
possible, you must optimize your hard disk (optimizing is also known as
unfragmenting/defragmenting, or compacting). Optimizing must be done with
MS-DOS 6.xx's DEFRAG or using a 3rd party utility program such as Norton
Utilities, or Central Point PC Tools. It is important to run these programs
outside the Microsoft Windows 3.1x environment. If you have already created a
permanent swap file, make sure you delete it using Control Panel before
optimizing your hard disk. It is not necessary to delete the permanent swap
file every time you optimize your hard disk, only when you want to increase
the size of the permanent swap file by optimizing, then re-creating it.
The Virtual Memory utility supports only disks that use 512-byte sectors for
the swap file. If 512-byte sectors are not being used, this indicates a
non-standard configuration such as a 3rd party disk partitioning driver.
The Virtual Memory utility (and Windows 3.1x itself) supports drives with
512-byte sectors that have been partitioned with the MS-DOS FDISK command.
NOTE: Certain OEM versions of MS-DOS have altered versions of FDISK that will
partition drives using sector sizes other than 512 bytes. Never run the
Virtual Memory utility on a drive that uses a partitioning driver in
CONFIG.SYS, with the exception of Compaq's ENHDISK.SYS. If you receive a
message concerning a corrupted swap file, use Control Panel to delete the
corrupted swap file and create a new one.



WIN.COM AUTOMATIC STARTUP PARAMETERS



386 Enhanced Mode Requirements


WIN.COM requirements to automatically start up in 386 enhanced mode:
- 80386 processor or above
- 1024 KB (1 MB) of free extended memory
- XMS driver loaded (HIMEM.SYS).
A typical installation requires a minimum of 182 KB of memory free at the
MS-DOS prompt to run 386 enhanced mode, assuming sufficient extended memory is
free. Windows 386 enhanced mode requires a minimum of 580 - 624 KB combined
conventional and extended memory to run.
386 enhanced mode can start up in low memory situations because it provides
virtual memory support; however, it may be extremely slow due to the large
amount of disk swapping it must perform.
All numbers are approximate and may vary widely depending on the configuration
(for example, Windows device drivers chosen, MS-DOS version, display adapter,
and so on). 128 KB of extended memory is recovered from shadow RAM usage on
COMPAQ 386 machines. Memory requirements take into account memory that can be
recovered from SMARTDrive (down to the minimum Windows cache size specified).



THE FREE SYSTEM RESOURCES PERCENTAGE



The Program Manager and File Manager About boxes in the Help menus of Windows
3.1x's 386 enhanced mode give percentage figures for free system resources and
free memory. To understand what the free system resources percentage means,
you must understand some of the anatomy of Windows's internal structure. The
part of Windows that runs Windows applications is made up of 3 main segments
called KERNEL, GDI (graphics device interface) and USER. KERNEL loads and runs
Windows applications and handles their memory management. GDI manages graphics
and printing. USER controls user input and output, including the keyboard,
mouse, sound driver, timer and communications ports. These 3 segments exist as
separate .EXE files and are located in \WINDOWS\SYSTEM. GDI has a storage area
limited to 64K, which is known as the local heap.
Currently, USER has 2 such areas, hence 128K storage. The free system
resources percentage reflects the remaining free percentage of USER or GDI
local heap space, whichever is lower. Although Windows 3.1x allows you to run
a large number of simultaneous Windows applications, it is not without
limitations. If you receive an "Out of memory" error and the Help About box
shows a large amount of free memory, look at the free system resources
percentage. Chances are you are low on system resources.
Every window and icon that is created requires USER local heap space.
It is theoretically possible to exhaust the system resources with only one
application, such as Program Manager, if enough objects are created by the
application.
Another important aspect of Windows application memory management that is not
included in the free system resources percentage is the number of selectors.
A selector is a memory pointer that is consumed with each memory allocation
made by a Windows application. Windows 3.1x has a fixed number of selectors
(8192 in 386 enhanced mode). If a Windows application allocates a very large
number of small data objects, it is possible to run out of selectors. This
will also produce an "Out of memory" error message.
Writing a Windows application to handle its own data objects more efficiently
can help in this situation. If you experience a chronic problem with a
particular application while few or no other applications are loaded, contact
the application vendor. Writing an application to handle data objects more
efficiently can help reduce "Out of memory" conditions.



386 ENHANCED MODE PERFORMANCE TIPS: GETTING THE MOST FROM YOUR MACHINE



The following suggestions should assist you in maximizing the performance of
your Windows 386 enhanced mode installation:
 1. USE SMARTDRIVE. The Microsoft SMARTDrive disk caching driver can produce
    the largest single Windows 3.1x performance improvement. Use SMARTDrive
    whenever possible.
 2. KEEP YOUR HARD DISK OPTIMIZED. A fragmented hard disk greatly impacts
    Windows's performance, especially when a temporary swap file and/or
    SMARTDrive is installed. Use a hard disk optimizer program (i.e. MS
    SCANDISK) on a weekly basis to keep your disk contiguous.
 3. CREATE A PERMANENT SWAP FILE. Using a permanent swap file improves
    performance over using a temporary one. Under Windows 3.1x, if supported
    by your hardware, also select the Use 32-Bit Disk Access check box in
    Control Panel by choosing the 386 Enhanced icon, choosing the Virtual
    Memory button, then choosing the Change button. See "386 Enhanced Mode and
    Virtual Memory" section of this application note for more info on
    permanent swap file allocation.
 4. TURN OFF GRAPHICS PORT TRAPPING. The speed of MS-DOS applications running
    under 386 enhanced mode can be noticeably improved by not selecting any of
    the Monitor Ports options in the Advanced section of the PIF Editor.
    The High Graphics option provides the widest range of MS-DOS application
    compatibility but is not required for most applications.
 5. TURN OFF THE FILESYSCHANGE= SETTING. Windows 3.1x 386 enhanced mode can
    monitor disk access by MS-DOS applications and send directory update
    messages to File Manager. This allows File Manager to be automatically
    updated by changes MS-DOS applications have made to files or directories.
    However, this option is not a necessity, and leaving it off (the default)
    speeds file access by MS-DOS applications. To disable this feature, set
    FileSysChange=no in the [386enh] section of SYSTEM.INI.
 6. TURN OFF THE RESERVEPAGEFRAME= SETTING. Turn this setting off if you do
    not require expanded memory support for MS-DOS applications. Turning this
    option off ensures that you're getting the most possible memory in Virtual
    MS-DOS Machines. To disable this feature, set ReservePageFrame=no under
    the [386enh] section of SYSTEM.INI.
 7. USE THE RIGHT NUMBER OF MS-DOS BUFFERS. If you are using SMARTDrive, set
    the number of MS-DOS disk access buffers in your CONFIG.SYS file to a
    maximum of 15 (BUFFERS=15). Using a greater number of buffers with
    SMARTDrive will actually decrease efficiency. If you are not using
    SMARTDrive (or any other 3rd party disk cache), use BUFFERS=30.
 8. USE THE LOWEST COMMON DISPLAY DRIVER. Using a display driver with a high
    resolution or large number of colors results in slower display
    performance. If you do not require the extra features of the display
    driver, use a driver with less capability.
 9. USE THE PROPER HARD DISK INTERLEAVE. Frequently, a hard disk is formatted
    with the wrong interleave at the dealer or factory. You can use a program
    such as Gibson Research SpinRite or Central Point DiskFix to verify that
    you are using the proper interleave. Programs like PowerQuest Partition
    Magic can correct your interleave without reformatting the hard disk.
10. ENABLE 32-BIT DISK ACCESS. 32-Bit Disk Access is a method for accessing
    the hard disk with fewer changes in the processor mode. Windows can do
    this by using a device driver that traps interrupt 13 calls and handles
    them itself. To take advantage of this feature of Windows/WfWG 3.1x, you
    need to have a compatible hard disk controller.
11. ENABLE 32-BIT FILE ACCESS IN WINDOWS/WFWG 3.11. To do this, open Control
    Panel, double-click the 386 Enhanced icon, click Virtual Memory, click
    Change, and check the box Use 32-bit File Access. This setting can be set
    properly ONLY if the 32-bit disk access is enabled.
    32-bit File Access will provide better performance on reading from and
    writing to files on hard disk(s). It will also speed up reads/writes
    to/from your hard disk(s) cache.



EXPANDED MEMORY FOR MS-DOS APPLICATIONS



Under 386 Enhanced Mode Windows/WfWG 3.1x


Expanded memory emulation is provided internally for MS-DOS applications
running under 386 enhanced mode. The only requirement is the presence of a 64K
contiguous page frame for LIM 3.2 compatibility. For more info on page frame
placement, see the "386 Enhanced Mode and the 384K Upper Memory Area (UMA)"
section above. Expanded memory for MS-DOS applications can be allocated and/or
limited through customizing PIF (Program Information File) settings by using
PIFEDIT.


External 386 Expanded Memory Managers


Some 386 EMMs have a special feature that allow 386 enhanced mode Windows to
turn the memory managers off when Windows is run. Windows can turn off
EMM386.EXE even if expanded memory is in use at the time. MS-DOS's HIMEM.SYS
+ EMM386.EXE, 386MAX.SYS, QEMM386.SYS and RM386.EXE provide the capability of
loading MS-DOS device drivers into free areas of the 384K UMA.


DPMI and VCPI Specifications


The MS-DOS Protected Mode Interface (DPMI) was developed by a group of
industry leaders including Borland, Eclipse, IBM, IGC, Intel, Lotus,
Microsoft, Phar Lap, Quarterdeck and Rational Systems. Several members of the
DPMI committee were also involved in the creation of the Virtual Control
Program Interface (VCPI). DPMI was primarily created by Microsoft, and VCPI
was formulated primarily by Phar Lap Software.


MS-DOS Extended Applications


MS-DOS extended applications execute code in the protected mode of the 80286,
80386 or newer processor. Creating an MS-DOS extended application requires a
method to switch the processor into protected mode and to allocate extended
memory.
Until DPMI, there was no standard method for MS-DOS extended applications to
perform these tasks and multitask memory with other applications on 80286,
80386, 80486, Pentium and newer CPUs.


Comparing VCPI to DPMI


VCPI and DPMI solve 2 different problems. VCPI provides an interface between
applications using MS-DOS extenders on a 80386 (and newer) machine and 386
EMMs. For example, the 386 EMMs (EMM386.EXE, QEMM386.SYS, 386MAX.SYS,
RM386.EXE) support the VCPI specification. VCPI allows applications using
MS-DOS extenders to run simultaneously with 386 EMMs on 80386 (and newer)
machines.
However, multitasking operating environments such as Windows 386 enhanced mode
have memory and protection models that are not compatible with the VCPI
interface.
DPMI was created so these environments can run extended MS-DOS applications.
Additionally, DPMI provides support for 80286 based machines, while VCPI does
not. DPMI has the capability of running MS-DOS extended applications on a
variety of processors and operating environments.