The information in this article applies to:
SUMMARYThis article discusses virtual memory issues under Win32s. These issues include how memory is managed, file mappings, and VirtualAlloc(). MORE INFORMATIONMemory ManagementWin32s 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 MappingsBecause 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. Additional query words:
Keywords : kbWin32s |
|
Last Reviewed: January 14, 2000 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |