Introduction
Microsoft®Windows® CE is a component-chemical operating system that customizes different features of the target device or platform. Original Equipment Manufacturer (OEM) or embedded system developer can select the required system modules and components to provide it to the operating system for the target platform. The selected modules and components determine its memory demand. A module represents a complete functional area, which can be indicated in the system software or will not be indicated. If this feature is not required, you can ignore the entire module. For example, a simple module named "serial" provides a function of the serial port, which can be included in the system or not included. Some large modules can be further divided into several components. This makes OEM vendors to customize smaller versions of these modules by using only the components of the OEM device. For example, a file system module includes several components of a RAM file system, a ROM file system, a registry, and a database. OEMs can (in accordance with certain restrictions) Components of the components of these file systems make it satisfied with the needs of the target system. To help OEM and embedded system developers make decisions, this is very useful for understanding the internal deposits of the given module or component. This article describes how the Windows CE 2.0 operating system uses memory, and lists the memory requirements of the main system modules and components in the selected Windows CE system configuration. Also explain how to use the Windows CE tool to see the memory demand in other configurations. For Windows CE version 2.0, Microsoft has created and tested several basic configurations of these modules and components. These configurations represent different sets of system performance, from the basic system with minimum user input and no display capabilities, to the full system with Microsoft Windows all appearance and feel on hand-held PC (H / PC). Each configuration is based on the previous configuration. The following table lists the tested configurations discussed herein.
Configuration Description Minimum Input System (MinInput) core, basic file system, registry, and basic user support. Basic user support includes: support for message queues, touchpads, keyboard input devices, sound, power, light emitting diode (LED) prompts, and machine idling. Minimum graphics display interface (MINGDI) MINININPUT and the smallest GDI (basic drawing element, device context). Minimum Communication (MINCOMM) MINININPUT and add communication stack (Transport Control Protocol / Internet Protocol [TCP / IP], point-to-point protocol, telephone application programming interface [TAPI], serial port, network device / driver interface description [NDIS], Infrared data connection [IrDa]). Windows User Interface (UI) Configuration (HPC2APPS) MINCOMM and add all and Window-related API functions (such as CREATEWINDOW), which is used in the H / PC.
System memory usage
Typical Windows CE devices include ROM and RAM memory. When the device is turned off, the device can continue to maintain the contents in the RAM by using a charged backup battery. System memory can be classified according to the situation described in the table below.
Memory Description ROM contains the executors and other system files of Windows CE. The text (code) and the read-only data portion of these files are portions that have not been decompressed to the execution position (XIP). RAM - Storage memory includes file systems (including registry and Windows CE databases). Includes readable / write data area. RAM - program memory works RAM.
The ROM contains files that are not extracted to execute location (XIP), including system executives, dynamic link libraries (DLLs), and bundled applications such as Microsoft Pocket Word. These files start from the boundaries of the page. ROM also includes various files used by these applications, such as font, sound, and bitmaps. Most of these files are compressed (except for some font exceptions). The read part of the code and the actuator and the DLLS are decompressed to the enabled execution position. Due to the read / write portion at the specified RAM, they are compressed there. In order to save space, many of these small files and compressed readable / write areas are placed in the slot of memory. These gaps are space placed in a code or read-only memory area in the ROM. The actuator or DLL in the compressed ROM is also possible. When this type of execution is run, the request switch program extracts the virtual page and loads them into the RAM. RAM is divided into two parts: storage memory and program memory. Storage memory includes registry, file system, and database. File systems include applications and data files installed or created by a user. All files in the file system are compressed. Program memory is used by the system and used to run the application. The user can re-adjust the division of memory memory and program memory at any time without restarting. User-installed application compresses resides in the file system. Codes and data needs to be decompressed to the program memory. Request for page support - When a user installed application is started, only a small portion of the application needs to be decompressed to program memory. In addition to the data part, each actant typically consumes a certain amount of program memory for its stack data. Stacks can usually be dynamically increased or decreased. Windows CE Version 2.0 memory usage
The following table shows memory usage on the HitachID9000 development platform with the SH3 microprocessor. The value of the RAM and stack is obtained when the MEMTOOL utility checks the system state after startup. These data are calculated as follows:
ROM (code and read data). The total part of all parts listed in the Romimage utility output module. RAM. The readable write data listed in the page through the MemTool utility and PPSH utility memory information (MI) command. STACK. The value of the stack is listed at the Total Page Total Bottom Page Total Page Total.
Although the MemTool and PPSH utilities show read-only data in RAM, this memory often represents shared memory representing the core. This shared memory is physically consumed on one page used by the core. Therefore, the module with a read-only page with a size of 1 is not calculated to the demand of the module RAM. The additional part includes a module that is more than 1 core and read-only page size. Due to these additional parts, the demand of RAM can be calculated as the sum of read only and readable / write parts.
MINININPUT
The MINININPUT system represents a system with a minimum input. It includes input support for core, basic file system, registry, and basic users. Basic users' input support includes: support for message queues, touch panels, keyboard input devices, sound, power, prompt LED, and idling control. The following table is displayed in kilobytes (k) in the detailed configuration value of the MinInput after the system is just started.
Module ROM (K) Ram (k) stack (k) nk.exe 119 5 4 FileSys.exe 57 6 1 gwes.exe 60 93 Coredll.dll 94
The following DLLs also included in the ROM of this configuration.
Module ROM (k) Toolhelp.dll 2 Keybddr.dll 8 Touch.dll 12
Mingdi
The MINGDI system represents a minimum system with GDI. The MINGDI system includes all components in the MINININPUT system and adds basic drawing elements and device context. The following table shows the detailed system configuration value of MINGDI after the system is just started.
Module ROM (k) RAM (K) Stack (k) NK.EXE 119 7 4 FileSys.exe 122 7 1 GWES.EXE 282 697 4 Coredll.dll 103 In addition to the DLLs listed in the MININPUT configuration, this configuration ROM The following DLLs are also included.
Module ROM (k) DDI.dll 29 Wavedev.dll 15
MINCOMM
MINCOMM configuration represents a system with minimum communication capabilities. The MINCOMM system includes all components in the Mininput system and adds some communication stacks (TCP / IP, PPP, TAPI, Serial, NDIS, and IRDA). The following table shows the detailed system configuration value of MINCOMM after the system is just started.
Module ROM (K) RAM (K) Stack (k) nk.exe 119 31 4 Filesys.exe 86 9 1 Gwes.exe 45 12 1 Device.exe 15 67 8 Coredll.dll 128
In addition to the DLLs listed in the MININPUT configuration, the ROM also includes the following DLLs.
Module ROM (K) PPP.dll 64 cxport.dll 6 Ircomm.dll 7 Winsock.dll 18 Secur32.dll 19 Schannel.dll 111 NTLMSsp.dll 14 AFD.DLL 39 ARP.DLL 19 NDIS.DLL 42 Ne2000.dll 21 TCPSTK .dll 98 Irdastk.dll 55 Tapi.dll 17 Unimodem.dll 21 Redir.dll 74 Netbios.dll 25 Wininet.dll 105 PCMCIA.DLL 29 Serial.dll 26
HPC2APPS
The HPC2APPS configuration represents a complete system for the Handheld PC. The HPC2APPS configuration includes all components in the MINCOMM system and adds all API functions associated with Windows (such as CREATEWINDOW).
Module ROM (K) RAM (K) Stack (k) nk.exe 119 K 46 4 FileSys.exe 122 K 9 4 Gwes.exe 508 K 724 7 Device.exe 15 K 78 10 Coredll.dll 122
In addition to the DLLs listed in the MINCOMM configuration, the following DLLs are also included in the ROM.
Module ROM (K) Fatfs.dll 54 Prnport.dll 5 pcl.dll 24 Atadisk.dll 9 Sramdisk.dll 7 Waveapi.dll 68 ole32.dll 150 oleaut32.dll 183 dhcp.dll 13 HWXUSA.DLL 86 Netui.dll 19
View ROM's use
You can see how the file is placed in the ROM by looking at the output of Microsoft Windows CE ROM Image Builder tool --Romimage.exe. (Many of this article are filed from the log file of the Image Builder tool) and is divided into multiple parts and put them in the ROM. These parts can be described below via the Windows CE development tool.
Partial description .Text code.RSRC resource data .DATA data.pdata debug and exception handler of each function of each function of the code part. CRT special part - C structure. Kdata special part - only in the core (nk.exe)
RomiMage is a command line tool. The header output from a typical Romimage section includes: the title of the program, the page size, and the starting position 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.copy d: /wince/release/odo2bpp.pdb to d : /WINCE/release/ddi.pdb for debugger.Setting PageSize to 1024DumpSymbols: pTOC found at00000e50MODULES SectionModule 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, the size of 116268 = 0x1c62C bytes. This actual size is expanded to the next 1024 byte boundary, 116736 = 0x1c800, and is placed in the ROM. This leaves a 468-byte "hole" and can be used by other files. Similarly, there is a 496-byte "hole" at the 0x8c63b210 address, which appears at the end of the last page of the Coredll.dll .rsrc section. After all .Text (code) section is placed, the Romimage starts to place the data parts of the less than one page into these "holes". For example, in a later modules section, the same Romimage log contains the following information:
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
Coredll.dll's first .DATA data section size is 4 bytes, and is placed in the first "hole", 0x8c600400 0x1c62c = 0x8c61ca2c. It only uses 4 bytes, move the next address to 0x8C61CA30 and reduces the "holes" to 464 bytes. The next smaller than one page is the data section of Device.exe, it requires 213 = 0xD5 bytes, and in the first "hole" remaining space is enough to accommodate it. It is placed here, becoming the address to 0x8c61cb05, and the "hole" is reduced to 251 bytes. Device.exe .data 8C61CA30H 213 213 276 FillerDevice.exe's .pdata section is 341 bytes, which is larger than this "hole", so it is placed to another "hole" - Coredll.dll resource part last one "Cave" on the page, the starting position is 0x8c63b210. Device.exe .pdata 8c63b210h 341 341 424 Filler Next .DATA or. PDATA section is smaller than the first "hole" remaining 251 bytes, with the debugger command interpreter shell.exe's .data part of 183 words Section. It is placed in the first "hole" next effective start address 0x8c61cb05. Shell.exe .pdata 8c61cb05h 183 183 208 FillerRomimage tool continues to work in this way until all parts are all placed. Any "holes" in the remaining unused are listed in 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 section is important because the size and quantity of the actuats and DLLs are different from different configurations. This will affect the size of the "holes" that can be used and affect the amount of memory required. To determine the ROM usage of each module, the sum of the sums of each part can be calculated according to the size of the module output from the Romimage tool - and the part of the "vulnerability" is removed. Because the fill portion is inserted into the "hole" that can be used, it does not increase the memory demand of the module.
View virtual memory
Use the MemTool tool to see each virtual memory page. MemTool provides a full image of 32 (MB) memory that is valid for each process. The memory image can be seen that the code and data are in the ROM or RAM. MemTool also shows a summary of current stack usage. The size of the stack can be dynamically increased or reduced as needed. The number of stacks display may not represent the maximum demand. They describe the status when the stack is checked using the MemTool tool. For example, the header of the FileSys.exe process memory image shows a variety of different usage. Each symbol represents a memory page and indicates the usage of the page: Memory usage for process 8c056d2c: 'filesys.exe' PID 1 slot base 040000 section PTR 8cfe4c0004000000 (1): ----------- ----------- R --------------------------------------- ---
04010000 (0): -CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
04020000 (0): CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
04030000 (0): ccccccccwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww --- r
04040000 (0): --------------------------------------------- ---- SSS ---- SSSS
04050000 (0): Ppppooooooo OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO / bath
Connecting characters (-) indicates that the page is reserved; lowercase R represents data in the RAM; uppercase C represents code in the ROM; uppercase W represents readable / write data in the RAM; uppercase R represents data in the ROM; uppercase S represents the stack; uppercase P represents the memory of the peripheral device (cannot be assigned by the core but can be mapped by GWES or device driver); uppercase O represents the target storage device. In addition to these symbols, lowercase C represents the code that is executing in the RAM. After the memory image, the MemTool tool displays the summary information. Similar information can also be obtained with PPSH tools and mi commands, which are shown below: Memory Usage for process 8c036d2c: 'filesys.exe' PID 1 slot base 040000 section PTR 8C5E7000 Page Summary: Code = 207 (0) DATAR / O = 2 r / w = 7 stack = 1 reserved = 13963 In the page summary, the value behind the Code represents the number of pages in the ROM. The numbers in parentheses represent the number of pages in the RAM. The data page represents only only read or read / write pages. The value behind Stack represents the number of pages used in the stack. To get the memory requirements information on other microprocessors and other platforms, you can use the ROM Image Builder, PPSH, or MemTool tool to view their output information. The full document of these tools can be found in Microsoft Windows CE Embedded Toolkit for Visual C ® 5.0.
Additional information about this
About Microsoft Windows CE Embedded Toolkit For Visual C 5.0, you can see the Microsoft Windows CE Web site. This tool will be provided to MSDN Library ordinary subscribers.
