لطفا منتظر باشید ...
Memory Basics
As with all computers, systems running Windows CE have both ROM (read only memory) and RAM (random access memory). Under Windows CE, however, both ROM and RAM are used somewhat differently than they are in a standard personal computer.
About RAM
The RAM in a Windows CE system is divided into two areas: program memory, also known as the system heap, and object store. The object store can be considered something like a permanent virtual RAM disk. Unlike the old virtual RAM disks on a PC, the object store retains the files stored in it even if the system is turned off.[1] This arrangement is the reason Windows CE systems such as the Pocket PC typically have a main battery and a backup battery. When the user replaces the main batteries, the backup battery's job is to provide power to the RAM to retain the files in the object store. Even when the user hits the reset button, the Windows CE kernel starts up looking for a previously created object store in RAM and uses that store if it finds one.The other area of the RAM is devoted to the program memory. Program memory is used like the RAM in personal computers. It stores the heaps and stacks for the applications that are running. The boundary between the object store and the program RAM is movable. The user can move the dividing line between object store and program RAM using the System Control Panel applet. Under low-memory conditions, the system will ask the user for permission to take some object store RAM to use as program RAM to satisfy an application's demand for more RAM.
About ROM
In a personal computer, the ROM is used to store the BIOS (basic input/output system) and is typically 64–128 KB. In a Windows CE system, the ROM can range from 4 to 32 MB and stores the entire operating system, as well as the applications that are bundled with the system. In this sense, the ROM in a Windows CE system is like a small read-only hard disk.
In a Windows CE system, ROM-based programs can be designated as Execute in Place (XIP). That is, they're executed directly from the ROM instead of being loaded into program RAM and then executed. This capability is a huge advantage for small systems in two ways. The fact that the code is executed directly from ROM means that the program code doesn't take up valuable program RAM. Also, since the program doesn't have to be copied into RAM before it's launched, it takes less time to start an application. Programs that aren't in ROM but are contained in the object store or on a Flash memory storage card aren't executed in place; they're copied into the RAM and executed.
About Virtual Memory
Windows CE implements a virtual memory management system. In a virtual memory system, applications deal with virtual memory, which is a separate, imaginary address space that might not relate to the physical memory address space that's implemented by the hardware. The operating system uses the memory management unit of the microprocessor to translate virtual addresses to physical addresses in real time.The key advantage of a virtual memory system can be seen in the complexity of the MS-DOS address space. Once demand for RAM exceeded the 640-KB limit of the original PC design, programmers had to deal with schemes such as expanded and extended memory to increase the available RAM. OS/2 1.x and Windows 3.0 replaced these schemes with a segment-based virtual memory system. Applications using virtual memory have no idea (nor should they care) where the actual physical memory resides, only that the memory is available. In these systems, the virtual memory was implemented in segments, resizable blocks of memory that ranged from 16 bytes to 64 KB in size. The 64-KB limit wasn't due to the segments themselves, but to the 16-bit nature of the Intel 80286 that was the basis for the segmented virtual memory system in Windows 3.x and OS/2 1.x.
Paged Memory
The Intel 80386 supported segments larger than 64 KB, but when Microsoft and IBM began the design for OS/2 2.0, they chose to use a different virtual memory system, also supported by the 386, known as a paged virtual memory system. In a paged memory system, the smallest unit of memory the microprocessor manages is the page. For Windows NT and OS/2 2.0, the pages were set to 386's default page size of 4096 bytes. When an application accesses a page, the microprocessor translates the virtual address of the page to a physical page in ROM or RAM. A page can also be tagged so that accessing the page causes an exception. The operating system then determines whether the virtual page is valid and, if so, maps a physical page of memory to the virtual page.
Windows CE implements a paged virtual memory management system similar to the other Win32 operating systems. Under Windows CE, a page is either 1024 or 4096 bytes, depending on the microprocessor. This is a change from Windows XP, where the page size is 4096 bytes for Intel microprocessors. For the CPUs currently supported by Windows CE, the 486, the Intel StrongARM, and the Hitachi SH4 use 4096-byte pages. The NEC 4100 uses a 4-KB page size in Windows CE 3.0 but a 1-KB page size in earlier versions of the operating system. The Hitachi SH3 uses 4096-byte pages in Windows CE 4.1, but it uses 1024-byte pages in earlier versions of Windows CE.Virtual pages can be in one of three states: free, reserved, or committed. A free page is, as it sounds, free and available to be allocated. A reserved page is a page that has been reserved so that its virtual address can't be allocated by the operating system or another thread in the process. A reserved page can't be used elsewhere, but it also can't be used by the application because it isn't mapped to physical memory. To be mapped, a page must be committed. A committed page has been reserved by an application and has been directly mapped to a physical address.All that I've just explained is old hat to experienced Win32 programmers. The important thing for the Windows CE programmer is to learn how Windows CE changes the equation. While Windows CE implements most of the same memory API set of its bigger Win32 cousins, the underlying architecture of Windows CE does impact programs. Before diving into the memory architecture of a Windows CE application, let's look at a few of the functions that provide information about the global state of the system memory.
Querying the System Memory
If an application knows the current memory state of the system, it can better manage the available resources. Windows CE implements both the Win32 GetSystemInfo and GlobalMemoryStatus functions. The GetSystemInfo function is prototyped below:
VOID GetSystemInfo (LPSYSTEM_INFO lpSystemInfo);
It's passed a pointer to a SYSTEM_INFO structure defined as
typedef struct {
WORD wProcessorArchitecture;
WORD wReserved;
DWORD dwPageSize;
LPVOID lpMinimumApplicationAddress;
LPVOID lpMaximumApplicationAddress;
DWORD dwActiveProcessorMask;
DWORD dwNumberOfProcessors;
DWORD dwProcessorType;
DWORD dwAllocationGranularity;
WORD wProcessorLevel;
WORD wProcessorRevision;
} SYSTEM_INFO;
The wProcessorArchitecture field identifies the type of microprocessor in the system. The value should be compared with the known constants defined in Winnt.h, such as PROCESSOR_ARCHITECTURE_INTEL. Windows CE has extended these constants to include PROCESSOR_ARCHITECTURE_ARM, PROCESSOR_ARCHITECTURE_SHx, and others. Additional processor constants are added as net CPUs are supported by any of the Win32 operating systems. Skipping a few fields, the dwProcessorType field further narrows the microprocessor from a family to a specific microprocessor. Constants for the Hitachi SHx architecture include PROCESSOR_HITACHI_SH3 and PROCESSOR_HITACHI_SH4. The last two fields, wProcessorLevel and wProcessorRevision, further refine the CPU type. The wProcessorLevel field is similar to the dwProcessorType field in that it defines the specific microprocessor within a family. The dwProcessorRevision field tells you the model and the stepping level of the chip.The dwPageSize field specifies the page size, in bytes, of the microprocessor. Knowing this value comes in handy when you're dealing directly with the virtual memory API, which I talk about shortly. The lpMinimumApplicationAddress and lpMaximumApplicationAddress fields specify the minimum and maximum virtual address available to the application. The dwActiveProcessorMask and dwNumberOfProcessors fields are used in Windows XP for systems that support more than one microprocessor. Since Windows CE supports only one microprocessor, you can ignore these fields. The dwAllocationGranularity field specifies the boundaries to which virtual memory regions are rounded. Like Windows XP, Windows CE rounds virtual regions to 64-KB boundaries.A second handy function for determining the system memory state is this:
void GlobalMemoryStatus(LPMEMORYSTATUS lpmst);
which returns a MEMORYSTATUS structure defined as
typedef struct {
DWORD dwLength;
DWORD dwMemoryLoad;
DWORD dwTotalPhys;
DWORD dwAvailPhys;
DWORD dwTotalPageFile;
DWORD dwAvailPageFile;
DWORD dwTotalVirtual;
DWORD dwAvailVirtual;
} MEMORYSTATUS;
The dwLength field must be initialized by the application before the call is made to GlobalMemoryStatus. The dwMemoryLoad field is of dubious value; it makes available a general loading parameter that's supposed to indicate the current memory use in the system. The dwTotalPhys and dwAvailPhys fields indicate how many pages of RAM are assigned to the program RAM and how many are available. These values don't include RAM assigned to the object store.The dwTotalPageFile and dwAvailPageFile fields are used under Windows XP and Windows Me to indicate the current status of the paging file. Because paging files aren't supported under Windows CE, these fields are always 0. The dwTotalVirtual and dwAvailVirtual fields indicate the total and available number of virtual memory pages accessible to the application.The information returned by GlobalMemoryStatus provides confirmation of the memory architecture of Windows CE. Making this call on an HP iPaq Pocket PC with 32 MB of RAM returned the following values:
dwMemoryLoad 0x18 (24)
dwTotalPhys 0x011ac000 (18,530,304)
dwAvailPhys 0x00B66000 (11,952,128)
dwTotalPageFile 0
dwAvailPageFile 0
dwTotalVirtual 0x02000000 (33,554,432)
dwAvailVirtual 0x01e10000 (31,522,816)
The dwTotalPhys field indicates that of the 32 MB of RAM in the system, I have dedicated 18.5 MB to the program RAM, of which 12 MB is still free. Note that there's no way for an application, using this call, to know that another 14 MB of RAM has been dedicated to the object store. To determine the amount of RAM dedicated to the object store, use the function GetStoreInformation.The dwTotalPageFile and dwAvailPageFile fields are 0, indicating no support for a paging file under Windows CE. The dwTotalVirtual field is interesting because it shows the 32-MB limit on virtual memory that Windows CE enforces on an application. Meanwhile, the dwAvailVirtual field indicates that in this application little of that 32 MB of virtual memory is being used.
An Application's Address Space
Although similar to the layout of a Windows XP application, the application address space of a Windows CE application has one huge difference that has an impact on applications. Under Windows CE, an application is limited to the virtual memory space available in its 32-MB slot and the 32-MB slot 1, which is used to load XIP-based DLLs. While 32 MB might seem like a fair amount of space available to an application that might run on a system with only 4 MB of RAM, Win32 application programmers, used to a 2-GB virtual address space, need to keep in mind the limited virtual address space available to a Windows CE application.
Figure 7-1 shows the layout of an application's 64-MB virtual address space, including the upper 32 MB used for XIP DLLs.
Figure 7-1: Memory map of a Windows CE application
Notice that the application is mapped as a 64-KB region starting at 0x10000. Remember, the lowest 64 KB of the address space for any application is reserved by Windows. The image of the file contains the code along with the static data segments and the resource segments. The actual code pages are not typically loaded in when the application is launched. Instead, each page is loaded on demand as the code in those pages is executed.
The read-only static data segment and the read/write static data areas typically take only a few pages. Each of these segments is page aligned. Like the code, these data segments are committed to RAM only as they're read or written to by the application. The resources for the application are loaded into a separate set of pages. The resources are read only and are paged into the RAM only as they're accessed by the application.The application's stack is mapped above the resource segment. The stack segment is easily recognized because the committed pages are at the end of the reserved section, indicative of a stack that grows from higher addresses down. If this application had more than one thread, more than one stack segment would be reserved in the application's address space.Following the stack is the local heap. The loader reserves a large number of pages, on the order of hundreds of kilobytes, for the heap to grow but commits pages only as necessary to satisfy memory allocations from malloc, new, or LocalAlloc calls. The remaining address space from the end of the reserved pages for the local heap to the start of the non-XIP DLLs mapped into the address space is free to be reserved and, if RAM permits, committed by the application. Non-XIP DLLs, those that are not execute-in-place in the ROM, are loaded into the application's address space starting at the 32-MB boundary in a top-down fashion. Non-XIP DLLs include those DLLs that are stored compressed in the ROM. Compressed ROM files must be decompressed into and executed from RAM when loaded.The upper 32 MB of the application's address space is reserved for XIP DLLs. Windows CE maps the code for the XIP DLLs into this space. Read/write segments for these DLLs are loaded into the lower 32 MB of the application's address space. Starting with Windows CE 4.2, resource-only DLLs loaded from ROM are loaded outside the entire 64-MB application space. These DLLs are loaded into the virtual memory space.[1] On mobile systems such as the Pocket PC, the system is never really off. When the user presses the Off button, the system enters a very low power suspended state.
