ROM Run-Time Image Creation
Other versions of this page are also available for the following:
.gif "A hyphen indicates that the information in this topic is not relevant for this platform, or that the platform does not support the API that is listed.")
.gif "A checkmark indicates that the information in this topic is relevant for this platform, and that any API listed is also supported on this platform.")
8/27/2008
ROM contains uncompressed files that execute in place (XIP), including the system executables and DLLs. These files start at the beginning of a page boundary. ROM also contains miscellaneous files that are used by these applications, such as fonts, waveform audio files (.wav), and bitmaps.
Files are divided into sections and placed into ROM. The following table shows these sections.
| ROM section | Description |
|---|---|
.text |
Code |
.rsrc |
Resource data |
.data |
Data |
.pdata |
Debugging and exception processing information for each function in the code section |
.CRT |
Special section — C++ construct |
.KDATA |
Special section — present in the kernel (Nk.exe) only |
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 XIP. The read-write sections are compressed because they are destined for RAM, where they will be uncompressed as needed.
To save space, many small data sections, referred to as Filler sections (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.
Because the size and number of executables and DLLs contained in ROM affects the size of the available holes, the ability to identify Filler sections is significant.
You can see exactly how the files are placed in ROM by inspecting the output of Romimage.exe. The numbers in the following code examples were obtained from the log files for Romimage.exe.
Note
Whenever Romimage.exe detects overlapped records, it fails and displays an error message.
The following code example shows the first few lines of output from a typical Romimage.exe session, which lists the program banner, the page size, and the beginning of the MODULES Section.
Windows CE ROM Image Builder v4.0 Copyright (c) 1995-2001 Microsoft Corporation
Copying f:\...\x86\debug\kernkitlprof.exe to f:\...\x86\debug\nk.exe for debugger
Copying f:\...\x86\debug\com_card.dll to f:\...\x86\debug\serial.dll for debugger
Copying f:\...\x86\debug\i82365.dll to f:\...\x86\debug\pcmcia.dll for debugger
Copying f:\...\x86\debug\kbd8042xtmsengus1.dll to f:\...\x86\debug\kbdmouse.dll for debugger
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 information in the MODULES Section is separated into the module name, ROM section, starting address in memory, length, psize, and vsize.
psize represents the physical size of the section in memory, which is the initialized data for a module and is page aligned. If the module is compressed, this represents the size of the compressed data.
vsize represents the virtual size of the section in memory, which is the total amount of memory that the section needs to run.
length represents the smaller of these two values, either psize or vsize. Typically, length is equal to psize, but is sometimes equal to vsize when corresponding to an uncompressed module because of page alignment.
For example, the first entry in the MODULES Section, nk.exe, has a size of 116,268 = 0x1c62c bytes. This actual size is rounded up to the next 1,024-byte page boundary (116,736 = 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.
The following code example shows how, after placing all the .text (code) sections, Romimage.exe begins placing the data sections that are smaller than a page into these holes.
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
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
filesys.exe .pdata 8cb36ad0h 2152 2149 2640
gwes.dll .data 8cb37338h 10796 10794 17828
gwes.dll .pdata 8cb39d64h 12456 12456 15768
device.exe .data 8c61ca30h 213 213 276 FILLER
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 uses 4 bytes, moving the next filler address to 0x8c61ca30, thus shrinking the hole to 464 bytes.
The next .data section that is smaller than a page is for Device.exe and requires 213 = 0xd5 bytes, which is also small enough to fit into the remaining space in this first hole. When it is placed there, the address changes to 0x8c61cb05, thus shrinking the hole 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 hole. This hole follows the last page of the Coredll.dll rsrc section, starting at 0x8c63b210.
device.exe .pdata 8c63b210h 341 341 424 FILLER
Shell.exe (183 bytes) is the next .data or .pdata section that is smaller than the remaining size of 251 bytes in the first hole. The .pdata section for the Debug shell (Shell.exe) is placed in the first hole at that next available address, 0x8c61cb05.
shell.exe .pdata 8c61cb05h 183 183 208 FILLER
Romimage.exe continues placing the small data sections into holes until all the sections have been placed. The Romimage.exe report lists any remaining holes. The following Romimage.exe report example lists the unfilled ROM holes:
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 number of executables and DLLs contained in ROM can change between different configurations. This 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.exe output for that module excluding 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.