虚拟内存布局 wince 5.0和 wince 6.0

Before Windows Embedded CE 6.0, there was a limit of 32 processes, and a 32
MB limit on virtual memory (VM) for each process. Also, all of the processes
shared the same 4 GB address space. For CE 6.0, the kernel process resides in
the upper 2 GB of the 4-GB (32-bit) virtual memory space, and the bottom 2 GB is
unique for each process. There is a limit of about 32,000 processes, due to the
number of handles that can be created. The practical limit on the number of
processes is bounded by the amount of physical memory.

In previous versions of Windows Embedded CE, the current application executed
in slot zero. In CE 6.0, slot zero, and all other process slots, are effectively
2 GB each.

Because virtual memory access is translated into hardware access through the
memory management unit (MMU), virtual memory code is CPU-dependent. ARM and x86
CPUs use hardware page tables, so the content of virtual memory is accessed
directly by the hardware. Other CPUs use a software translation look-aside
buffer (TLB) miss handler for which the content of virtual memory needs to be
filled.

The following list shows the design goals for virtual memory management in CE
6.0:

Large amount of virtual memory per process

No preset number of processes limit

Protection between processes

Mimimalization of CPU-dependent code

Efficient virtual memory allocation

Efficient TLB miss handling

The following table shows the CE 6.0 virtual memory map.

Mode	Range	Size	Description	Comments
Kernel	0xF0000000 - 0xFFFFFFFF	256 MB	CPU-specific VM	System call trap area. Kernel data page.
Kernel	0xE0000000 - 0xEFFFFFFF	256 MB	Kernel VM, CPU-dependent	Kernel space virtual memory, unless disallowed by the CPU, such as SHx.
Kernel	0xD0000000 - 0xDFFFFFFF	256 MB	Kernel VM	Kernel space virtual memory, shared by all servers and drivers loaded in kernel.
Kernel	0xC8000000 - 0xCFFFFFFF	128 MB	Object store	RAM based storage for RAM file system, CEDB databases, and RAM-based registry. Legacy data store.
Kernel	0xC0000000 - 0xC7FFFFFF	128 MB	Kernel XIP DLLs	XIP DLLs for the kernel and all servers and drivers loaded in the kernel.
Kernel	0xA0000000 - 0xBFFFFFFF	512 MB	Statically mapped Uncached	Direct access to physical memory bypassing the CPU cache.
Kernel	0x80000000 - 0x9FFFFFFF	512 MB	Statically mapped Cached	Direct access to physical memory accessed through the CPU cache.
User	0x7FF00000 - 0x7FFFFFFF	1 MB	Unmapped for protection	Buffer between user and kernel spaces.
User	0x70000000 - 0x7FEFFFFF	255 MB	Shared system heap	Shared heap between the kernel and processes. Kernel and kernel servers can allocate memory in the heap and write to it. Read-only for user processes. Enables a process to get data from a server without having to make a kernel call.
User	0x60000000 - 0x6FFFFFFF	256 MB	RAM-backed map files	RAM-backed map files are mapped at fixed location for backward compatibility. RAM-backed map files are memory-mapped file objects that do not have an actual file beneath them. They are acquired by calling CreateFileMapping with hFile set to INVALID_HANDLE_VALUE. This region provides backward compatibility for applications that used RAM-backed map files for cross-process communication, expecting all processes to map views at the same virtual address.
User	0x40000000 - 0x5FFFFFFF	512 MB	User-mode DLLs Code and data	DLLs are loaded at the bottom of the stack and grow up: Based starting at 0x40000000. Code and data are intermixed. A DLL loaded in multiple processes loads at the same address in all processes. Code pages share the same physical pages. Data pages have unique physical pages for each process.
User	0x00010000 - 0x3FFFFFFF	1 GB	Process User allocatable VM	Executable code and data. User VM (heap) virtual allocations: VM allocations start above the exe and grow up.
User	0x00000000 - 0x00010000	64 KB	CPU-dependent user kernel data	User kernel data is always read-only for user. Depending on CPU, it can be kernel read/write (ARM), or kernel read-only (all others).

The following list shows some points of note from the table above:

User-mode DLLs now grow from 0x40000000 upward, instead of downward.

Users can call VM functions only on the memory that they allocate with VirtualAlloc.
They cannot perform VM operations on kernel-allocated VM in user space, such as
stacks, memory-mapped file views, and DLL code or data.

The kernel can read and write to the shared heap area, and user processes
can only read to the shared heap area. The purpose of this area is to allow the
system to communicate with client processes more efficiently. However, because
all processes can read information from the shared heap, do not store any
security-sensitive information, such as a password, in the shared heap.

There is always an unmapped area of at least 64 KB between the regions to
protect access span regions.


Virtual Memory Interface for User
Processes

There can be only one virtual memory
mapped at a time. You cannot access the memory of other processes directly
through their virtual memory address window. The virtual memory functions can be
used only on an address that was allocated by a process. For example, an
application cannot call VirtualProtect
on a code address to change its own protection.

The *Ex versions of the following
functions are intended for use by servers to access the virtual memory of the
client process.

The following functions comprise the
virtual memory interface for user processes:

VirtualAlloc

VirtualAllocEx

VirtualFree

VirtualFreeEx

VirtualProtect

VirtualQuery

WriteProcessMemory

ReadProcessMemory

VirtualProtectEx

VirtualQueryEx



Kernel Virtual Memory Interface

The following *Ex functions take a
process handle as a parameter so that you can perform operations on the virtual
memory of another process. The following list shows the virtual memory interface
for the kernel:

VirtualCopy

VirtualCopyEx

LockPages

UnlockPages

CeVirtualSharedAlloc

AllocPhysMem

CreateStaticMapping

VirtualSetAttributes

DeleteStaticMapping



Benefits of the Virtual Memory Layout

The number of processes is not limited to 32.

The amount of memory available to each process is not limited to 32 MB.

Switching processes on ARM and x86 is faster because it is simpler to make
use of the hardware page tables. The time to switch processes for MIPS and SHx
remains about the same.

TLB miss handling is faster on MIPS and SHx because of simpler address space
access checking. The time to handle TLB misses on ARM and x86 remains about the
same.



Tradeoffs of the Virtual Memory Layout

The virtual memory for every process is no longer accessible at all times,
but the virtual memory for the kernel process and the current process are
accessible at all times. Therefore, accessing the memory of another process,
particularly buffer parameters that are passed to a server, is no longer as
simple as mapping a pointer.

More complicated reference counting.

More complicated interprocess communication (IPC) and buffer
passing.



See Also

Other Resources

Kernel
Functionality Modifications: Windows CE 5.0 vs. Windows Embedded CE 6.0
Kernel API
Modifications: Windows CE 5.0 vs. Windows Embedded CE 6.0