Microsoft Windows CE Memory Use

John Murray

September 1997

Introduction

Microsoft® Windows® CE is a componentized operating system that can be customized for different target devices, or platforms. An original equipment manufacturer (OEM) or embedded system developer can select the system modules and components that will be provided in the operating system for the target platform. The selected modules and components determine its memory requirements.

A module represents a complete functional area that is either present or not present in the system software. If the functionality is not needed, the entire module is omitted. For example, all serial port functionality is provided within a single module, named "serial," which is either included or not.

Some large modules are further partitioned into components. This allows the OEM to custom-build smaller versions of these modules by including only the components needed by the OEM device. For example, the file system module includes components for a RAM file system, a ROM file system, the registry, and the database. The OEM can mix and match these file system components (with some constraints) to meet the needs of the target platform.

To help the OEM and embedded system developer make design decisions, it is useful to be able to know the memory consumption of a given module or component. This article describes how the Windows CE 2.0 operating system uses memory and lists the memory requirements for the major system modules and components for selected Windows CE system configurations. It also describes how to use the Windows CE tools to find these memory requirements for other configurations.

For Windows CE version 2.0, Microsoft has created and tested several base configurations of these modules and components. These configurations represent different sets of system capabilities, ranging from a base system with minimal user input and no display capabilities, to the full look and feel of Microsoft Windows in the Handheld PC (H/PC).

Each configuration builds on previous configurations. The following table lists the tested configurations that are examined in this paper.

System Memory Use

A typical Windows CE device contains ROM and RAM memory. The device maintains the contents of RAM even when the device is turned off by refreshing with a backup battery.

The system memory can be categorized as described in the following table.

ROM contains the uncompressed files that execute in place (XIP), including the system executables, dynamic-link libraries (DLLs), and bundled applications such as Microsoft Pocket Word. These files start at the beginning of a page boundary. ROM also contains the miscellaneous files used by these applications, such as fonts, audio, and bitmaps. Most miscellaneous files are compressed (with the exception of a few fonts). Code and read-only sections for the executables and DLLs are uncompressed to enable execute-in-place. The read/write sections are compressed because they are destined for RAM, where they will be compressed.

To save space, many of these small miscellaneous files and compressed read/write sections are placed into holes in memory. A hole is the space remaining on the last page after a code or read-only memory section is placed in ROM.

It is also possible to compress an executable or DLL in ROM. When such an executable runs, the on-demand paging uncompresses the required pages and loads them into RAM.

RAM is divided into two parts: storage memory and program memory. The storage memory contains the registry, file system, and database. The file system contains the application and data files installed or created by the user. All files in the file system are always compressed. The program memory is used by the system and running applications. The user can adjust the division of RAM into the storage and program memory at any time without rebooting.

User-installed applications reside compressed in the file system. The code and data need to be uncompressed into the program memory for execution. On-demand paging is supported—when a user-installed application is started, only a small part of the application needs to be uncompressed into program memory.

In addition to the .data section, each executable usually consumes some amount of program memory for its heap and stack data. The heap and stack usually grow and shrink dynamically.

Memory Use for Windows CE Version 2.0

The following tables show the memory usage on the Hitachi D9000 Development Platform with the SH3 microprocessor. The RAM and stack values are obtained after startup at the time the Memtool utility inspected the system state. These numbers are calculated as follows:

• ROM (code and read-only data). Sum of all sections listed in the Romimage utility output for that module.
  
  
• RAM. Read/write data listed in the page summary by the Memtool utility and the Ppsh utility memory information (mi) command.
  
  
• Stack. Value listed for stack in the page summary by the Memtool utility and the Ppsh utility mi command.

Although the Memtool and Ppsh utilities display read-only data in RAM for each process, this memory often represents shared memory that is allocated by the kernel. This shared memory physically consumes only one page that is used by the kernel. Accordingly, modules with a read-only page size of 1 are not counted toward that module's RAM requirements. Exceptions include the kernel and modules with read-only page sizes greater than 1. For these exceptions, the RAM requirement is calculated as the sum of the read-only and read/write sections.

MinInput

The MinInput system represents a minimal input system. This includes the kernel, base file system, registry, and base user-input support. Base user-input support includes: support for message queues, touch pad, keyboard input devices; audio, power, notification LED, and idle.

The following table contains valuesin kilobytes (K) for a retail MinInput configuration immediately after system startup.

This configuration also includes the following DLLs in ROM.

MinGDI

The MinGDI system represents a minimal system with a GDI. The minimal GDI includes all of the components in the MinInput system, and adds base drawing primitives and device contexts.

The following table contains values for a retail MinGDI configuration immediately after system startup.

In addition to the DLLs listed under the MinInput configuration, this configuration also includes the following DLLs in ROM.

MinComm

The MinComm configuration represents a system with minimal communications capabilities. The MinComm system includes all of the components in the MinInput system, and adds the communications stacks (TCP/IP, PPP, TAPI, Serial, NDIS, and IRDA).

The following table contains values for a retail MinComm configuration immediately after system startup.

In addition to the DLLs listed for the MinInput configuration, this configuration also includes the following DLLs in ROM.

HPC2Apps

The HPC2Apps configuration represents the complete system that appears on the Handheld PC. The HPC2Apps configuration includes all of the components in the MinComm system, and adds all window-related API functions (such as CreateWindow).

In addition to the DLLs listed for the MinComm configuration, this configuration also includes the following DLLs in ROM.

Viewing ROM Use

It is possible to see exactly how the files are placed in ROM by inspecting the output of the Microsoft Windows CE ROM Image Builder utility, Romimage.exe. (The numbers in this paper are obtained from the Image Builder utility log files.)

Files are divided into sections and placed into ROM. The sections are characterized as follows by the Windows CE development tools.

Romimage is a command-line utility. The first few lines of output from a typical Romimage session list the program banner, the page size, and the beginning of the MODULES section:

Windows CE ROM Image Builder  v1.0  Copyright Microsoft 1995.
Copying d:\WINCE\release\odo2bpp.dll to d:\WINCE\release\ddi.dll for debugger.
Copying d:\WINCE\release\odo2bpp.pdb to d:\WINCE\release\ddi.pdb for debugger.
Setting PageSize to 1024
DumpSymbols: pTOC found at 00000e50
MODULES Section
Module       Section  Start     Length  psize   vsize   Filler
------------ -------- --------- ------- ------- ------- ------
nk.exe       .text    8c600400h  116736  116736  116268
nk.exe       .pdata   8c61cc00h    4096    4096    3864
coredll.dll  .text    8c61dc00h  119808  119296  118987
coredll.dll  .rsrc    8c63b000h    1024    1024     528
...

The first entry in the MODULES section, Nk.exe, has a size of 116268 = 0x1c62c bytes. This actual size is rounded up to the next 1024-byte page boundary, 116736 = 0x1c800, and placed in ROM. This leaves a hole of 468 bytes available for miscellaneous files. Similarly, a hole of 496 bytes is available at address 0x8c63b210, at the end of the last page that contains the Coredll.dll .rsrc section.

After placing all the .text (code) sections, Romimage begins placing data sections that are smaller than a page into these holes. For example, the same Romimage log contains the following information, later in the MODULES section:

Module       Section  Start     Length  psize   vsize   Filler
------------ -------- --------- ------- ------- ------- ------
...
coredll.dll  .data    8c61ca2ch       4       4     200 FILLER
coredll.dll  .pdata   8cb32800h    4868    4866    8064
filesys.exe  .data    8cb33b04h   12236   12234   21376
filesys.exe  .pdata   8cb36ad0h    2152    2149    2640
gwes.exe     .data    8cb37338h   10796   10794   17828
gwes.exe     .pdata   8cb39d64h   12456   12456   15768
device.exe   .data    8c61ca30h     213     213     276 FILLER
device.exe   .pdata   8c63b210h     341     341     424 FILLER
fatfs.dll    .data    8c659c84h     366     366     504 FILLER
fatfs.dll    .pdata   8cb3ce0ch    1324    1322    1624
shell.exe    .data    8cb3d338h    1608    1605    2864
shell.exe    .pdata   8c61cb05h     183     183     208 FILLER
...

The first .data section for Coredll.dll is 4 bytes, and is placed at the first available hole, 0x8c600400 + 0x1c62c = 0x8c61ca2c. It consumes four bytes, moving the next filler address to 0x8c61ca30 and shrinking the hole to 464 bytes.

The next .data section smaller than a page is for Device.exe and requires 213 = 0xd5 bytes, which is also small enough to fit within the remaining space in this first hole. It is placed there, the address changes to 0x8c61cb05, and the hole shrinks to 251 bytes.

device.exe   .data    8c61ca30h     213     213     276 FILLER

The .pdata section for Device.exe, 341 bytes, is larger than the remaining space in this hole, so it is placed into another—the hole following the last page of the Coredll.dll resource section, starting at 0x8c63b210.

device.exe   .pdata   8c63b210h     341     341     424 FILLER

The next .data or .pdata section smaller than the remaining size of 251 bytes in the first hole is the .data section for the debug shell, Shell.exe, at 183 bytes. It is placed in the first hole, at that next available address, 0x8c61cb05.

shell.exe    .pdata   8c61cb05h     183     183     208 FILLER

The Romimage tool continues in this fashion until all the sections have been placed. Any remaining holes are listed as part of the report:

Unfilled ROM Holes (Address,Length):
8c9cfbf8h       8 8caef3f8h       8 8cb253f8h       8 8cb2bff8h       8
8c769bf9h       7 8c8d4ffah       6 8c8f37fah       6 8c98dffah       6
8cb16ffah       6 8cb1d7fah       6 8cb327fah       6 8c61dbfbh       5
8c6e6ffbh       5 8c763ffbh       5 8c855ffbh       5 8c935bfbh       5
8c9877fbh       5 8c7537fch       4 8c765bfch       4 8c7bcffch       4
8c7d3bfch       4 8c80dbfch       4 8c82f3fch       4 8c8f27fch       4
8c938ffch       4 8c9c17fch       4 8c9e23fch       4 8ca6e7fch       4
8cacfbfch       4 8cb20bfch       4 8c61cbfdh       3 8c659ffdh       3
8c6e13fdh       3 8c6e23fdh       3 8c6e87fdh       3 8c6ee7fdh       3
8c63b3feh       2 8c74fffeh       2 8c785ffeh       2 8c7b8ffeh       2
8c7c23feh       2 8c9717feh       2 8c99d7feh       2 8cb09ffeh       2
8cb227feh       2 8c63afffh       1 8c65a3ffh       1 8c6ea7ffh       1
8c788fffh       1 8c793fffh       1 8c9727ffh       1 8c9a8bffh       1
8ca83bffh       1 8cacf7ffh       1 8cb047ffh       1 8cb0bfffh       1

The ability to identify the FILLER sections is significant because the size and number of executables and DLLs can change between different configurations. This in turn affects the size of the available holes, and can affect the total amount of memory required.

To determine ROM use by each module, calculate the sum of all sections listed in the Romimage utility output for that module—except for those sections that are listed as filler. Because the filler is inserted into the available holes, it does not increase the memory requirement for that module.

Viewing Virtual Memory

It is possible to examine every page of virtual memory with the Memtool utility. Memtool provides a complete memory map for the 32 megabyte (MB) slot available to each process. The memory map notes whether the code and data is in ROM or RAM.

Memtool also displays a summary of the current stack usage. The stack size changes dynamically, growing and shrinking as needed. The stack numbers shown may not indicate a maximum requirement. They describe the state of the stack at the time it was examined by the Memtool utility.

For example, the first few lines of the memory map for the Filesys.exe process demonstrate a variety of different uses. Each symbol represents a page of memory and indicates how that page is used:

Memory usage for Process 8c056d2c: 'filesys.exe' pid 1
Slot base 04000000  Section ptr 8cfe4c00
    04000000(1): ----------------------r-----------------------------------------
    04010000(0): -CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
    04020000(0): CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
    04030000(0): CCCCCCCCCCWWWWWWWWWWWWWWWWWWWWW---R
    04040000(0): -------------------------------------------------SSS----SSSS
    04050000(0): PPPPOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO

The hyphen character (-) indicates that the page is reserved; lowercase r indicates data in RAM; capital C indicates code in ROM; W indicates read/write data in RAM; R indicates data in ROM; S indicates stack; P indicates peripheral memory (not allocated through the kernel but mapped by Gwes or device drivers); and O indicates object store. In addition to these symbols, lowercase c indicates code executing from RAM.

After the memory map, the Memtool utility displays summary information. Similar information is also available from the Ppsh utility MI command , which appears as follows:

Memory usage for Process 8c036d2c: 'filesys.exe' pid 1
Slot base 04000000  Section ptr 8c5e7000
Page summary: code=207(0) data r/o=2 r/w=7 stack=1 reserved=13963

In the page summary, the value associated with code indicates the number of pages in ROM. The number in parentheses indicates the number of pages in RAM. The data pages indicate read-only and read/write, respectively. The value associated with stack indicates the number of pages in use by the stack.

To obtain the memory requirement information for other microprocessors and other platforms, examine the output from the ROM Image Builder and the Ppsh or Memtool utilities. Complete documentation for these utilities is available in the Microsoft Windows CE Embedded Toolkit for Visual C++® 5.0.

For More Information

For the Microsoft Windows CE Embedded Toolkit for Visual C++ 5.0, see the Microsoft Windows CE Web site (http://www.microsoft.com/windowsce/developer/prodinfo/vcceembed.htm). The toolkit will also be available to Universal Subscribers of the MSDN Library.

Also, be sure to take a look at the following articles, all available in the MSDN Library:

"Embedded Development with Microsoft Windows CE 2.0," by Franklin Fite Jr. and Randy Kath.

"Introducing the Windows CE Embedded Toolkit for Visual C++ 5.0," by David Pellerin.

"Microsoft Windows CE Display Drivers and Hardware," by Jason Black and Jon Christiansen.

"Microsoft Windows CE Graphics Features," by Jon Christiansen.

"The Microsoft Windows CE Communications Model," by Guy Smith.

"Real-Time Systems with Microsoft Windows CE," by John Murray.

"The Win32 Programming Model: A Primer for Embedded Software Developers," by David Pellerin.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only.

MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.