Virtual Memory and Win32s

Last reviewed: January 3, 1997
Article ID: Q124137
The information in this article applies to:
  • Microsoft Win32s versions 1.30, 1.30a, 1.30c

SUMMARY

This article discusses virtual memory issues under Win32s. These issues include how memory is managed, file mappings, and VirtualAlloc().

MORE INFORMATION

Memory Management

Win32s does not manage the virtual memory by itself. Win32s sits on top of the Win386 virtual memory manager (VMM). The Win32s VxD and Win386 must cooperatively manage the memory.

Windows sets the amount of virtual memory (VM) at boot time, based on the amount of free physical RAM. Windows is also responsible for managing the physical pages.

The pages that map to the Win32-based application's code and data are reserved at application initialization time. This decreases the available virtual memory but not necessarily the available RAM. In 16-bit Windows- based applications, the selectors are initialized at initialization time, but they are marked as discarded and are loaded only when the segments are touched. This may lead you to think that a Win32 version of you application takes significantly more memory than its 16-bit Windows version. However, in reality, the available memory drops more when the Win32-based application is loaded, even though the actual RAM usage during execution may be lower.

NOTE: Code pages are never backed by the .EXE file, but are always backed by the pagefile.

File Mappings

Because of the way memory is managed, you cannot have a file mapping that is larger than the amount of virtual memory available on Win32s. This works fine on Windows NT and Windows 95. Win32s allocates regular virtual memory for the memory mapped section even though it does not need swap space, and the amount of VM set by Windows is too small to use for mapping large files.

VirtualAlloc()

VirtualAlloc() reserves or commits pages in virtual memory. When virtual memory is allocated (committed), the page is still not present. Touching the page will make it present and initialized to zero. Unlike Windows NT, some of the address space on Win32s is not allocated by VirtualAlloc(). You can use VirtualQuery() for every address in the USER address space, as reported by GetSystemInfo().

VirtualAlloc() allocates private memory, so one process cannot commit or free memory reserved by another process. This is true for all Win32 platforms. However, on Win32s, the memory is still accessible by all processes because there is a shared address space provided by Windows.

NOTE: A "not enough memory" error occurs if you reserve memory using VirtualAlloc() in one application and then try to commit the memory from a second application. This happens because the call to commit from the second application is interpreted as a call to reserve. You need to commit at an address that is not available such as an address already reserved by the first application.


KBCategory: kbprg
KBSubcategory: W32s
Additional reference words: 1.30 1.30a 1.30c


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: January 3, 1997
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.