How to Analyze OS ROM Size (Windows Embedded Compact 7)
When you design a Windows Embedded Compact 7 OS for a device that has specific ROM requirements, the size of the OS is an important factor. After you build the OS, you may want to calculate the size of the OS as it will appear in ROM. (This is not the same size as nk.bin!) You may also want to examine the ROM footprint of individual modules and files, which may influence your decision about which features to include in the OS. During your investigation, you can analyze the Sysgen configuration of your OS to learn which modules are included. This article, which is based on Johnson Shih’s video, Controlling ROM Size, includes:
The composition of ROM
Before we discuss the size of the OS and its individual modules, let’s review the end of the build process. (For complete information, see Windows Embedded Compact 7 Build Process.) During the build, all of the files that the build includes in the OS image are copied to the flat release directory (%_FLATRELEASEDIR%). Make Binary Image tool (MakeImg.exe) then uses a number of configuration files from the flat release directory to combine the modules into a single image file, which is typically called nk.bin. Nk.bin is the file that you download to your device.
During the Makeimg step, several Binary Image Builder (.bib) Files are merged into one file called ce.bib, which defines all of the modules and files to include in the OS image and where they will be placed within ROM on the device. You can find ce.bib in the flat release directory. It provides a lot of useful information for ROM analysis. Within ce.bib, we are interested in two sections: MODULES and FILES. All of the files listed under MODULES and FILES are pulled into nk.bin. The following is an excerpt from ce.bib (some lines have been removed for readability).
In your own ce.bib, you will notice that many lines are surrounded by @CESYSGEN IF and @CESYSGEN ENDIF. These are Cesysgen Conditional Statements. Conditional statements are important because they prevent modules and files that the OS does not need from being included in the run-time image. The following is an excerpt from ce.bib that shows conditional statements.
Files and modules that are included in the OS are listed between the @CESYSGEN IF and @CESYSGEN ENDIF lines for the corresponding feature. When there are @CESYSGEN IF and @CESYSGEN ENDIF statements without a line between them, then the code and data for that feature are not included in the OS. In the preceding example, the modules corresponding to Cryptdll and Winsock are included in the OS. The modules for Bluetooth utilities and Bluetooth settings are not included.
Modules
The MODULES section is for binary executables. The executables that are listed in the MODULES section are “fixed up” during the Makeimg build step. That is, Romimage.exe chooses which virtual addresses the executables will run from and sets them up to always run from those addresses. It doesn’t make sense to put non-executable files in the MODULES section because Romimage.exe can’t fix these up for you.
DLL files contain a Portable Executable (PE) header, a section table, and various sections. When a DLL is in the MODULES section, Makeimg parses it and strips off the PE header and the section table before fixing it up, so the PE header and the section table do not end up in ROM, as shown in the following figure. Note that because of the 4 KB-page alignment in ROM, information in ROM may not be arranged exactly as it is in the DLL file.
Files
The FILES section is for non-executable files such as data, resource DLLs, audio, bitmap files, and so on. The FILES section is also for managed code, which is not considered executable because it is intermediate code, not native code. By default, files in the FILES section are compressed. If you don’t want a file to be compressed, give the file a U attribute such as with wince.nls and tahoma.ttf in the earlier ce.bib excerpt.
Find the ROM footprint
You can analyze the OS size from two perspectives: you can extract the size of the OS and its individual modules and files directly from nk.bin, or you can look in the flat release directory. Each method has its advantages and disadvantages. You can extract the exact sizes from nk.bin, but because a lot of the information is stripped out during the Makeimg process, you have limited information to work with. On the other hand, the flat release directory contains a complete set of all of the files that are included in the OS in addition to configuration files that are used during the build process. However, in many cases, the file sizes in the flat release directory are not the same as the file sizes in ROM. You may want to use a combination of both methods. The following sections on total OS size, module size, and file size consider both approaches.
Find the total OS size
Although nk.bin contains your OS image, the size of the nk.bin file is not necessarily the size of the OS in ROM on your device. This difference is because nk.bin is a set of records, not a byte-for-byte image of the data in ROM. The OS size in ROM is typically larger than the size of nk.bin.
You can, however, extract the exact size of the ROM footprint of the OS from nk.bin by using the Viewbin Tool provided with Windows Embedded Compact 7 in %_WINCEROOT%\public\common\oak\bin\i386. To find the size of the OS in ROM, use the Viewbin command-line option –t. This option prints a table of contents for the OS image. In particular, look at the lines for Physical First and Physical Last under the ROMHDR section:
Physical First and Physical Last indicate the exact start and end of your OS in ROM on your device. You can determine the exact ROM footprint size by subtracting the value of Physical First from the value of Physical Last. In this example, the size of the ROM footprint is 0x02422F40, which is 37,891,904 bytes.
You can use Viewbin with the –t option to display other information about the contents of ROM, such as the total number of modules and files that are included in the OS. For example, you can use these totals to check if any modules or files were added between builds. However, because most of the extra information was stripped out by the Makeimg process, there is only limited information available in nk.bin to do an analysis. Therefore, you may want to analyze the individual module and file sizes and the OS configuration as described in this article to gain more detailed information about what is contributing to the OS size.
Find the size of a module
You can find the ROM footprint of individual modules directly from nk.bin. To extract module information from nk.bin, you can use Viewbin with the command-line option –o. The report contains detailed information about all of the individual modules and files. The following is an excerpt that describes ipconfig.exe.
The timestamp and file size of ipconfig.exe are identical to what you would see if you had used Viewbin with the command-line option –t. (These values are the same as what you would see for the ipconfig.exe file in the flat release directory.) However, the –o option provides you with additional information that you can use to calculate the exact amount of space that ipconfig.exe occupies in ROM. When Makeimg fixes up a module, it may spread the module out in ROM by dividing it into sections, where each section corresponds to a region of memory. In the Viewbin –o report, the details for each module contain an entry for e32_objcnt, which gives you the number of sections for that module. This is the number of areas in which Makeimg spreads that module out within ROM.
The Viewbin –o report then lists some information for each section of the module: o32_rom[0], o32_rom[1], and so on. Each section contains an entry for physical size (o32_psize), which is the exact size of that region in ROM. You can sum the sizes to obtain the exact ROM footprint of the module. The preceding excerpt shows that ipconfig.exe is spread into two regions of ROM. The sizes of the two regions are 0x4000 bytes and 0x112 bytes, respectively. The total size is 0x4112, which is 16,658 bytes. You could create a tool that parses the report and sums the o32_psize values so that you can list the total ROM footprint size for each module.
You can also look at the file size in the flat release directory, but be aware that when a module ends up in ROM, it is a different size than what you see in the flat release directory. This occurs for two reasons:
- Information removal. The Makeimg step removes the PE header and section table before it does the fix-up. Because only the useful information is pulled into ROM, the size of the module is reduced a bit.
- Page alignment. In ROM, the page size is 4 KB. Therefore, if the
.textsection of a module is 4 KB + 1 byte, for example, it will occupy 8 KB in ROM. This factor can increase the module size somewhat.
In summary, keep in mind that the sizes of the modules that you see in the flat release directory may not be the same as they are in ROM, because they are fixed up and possibly spread out differently in ROM.
Find the size of a file
For files listed in the FILES section of ce.bib, the size in ROM is more straight-forward. The size just depends on whether a file is compressed. If a file is uncompressed, the size of the file in the flat release directory is the same as it will be in ROM. If the file is compressed, its footprint in ROM will be smaller. Note that using compression is a trade-off. When you use compression, the file size in ROM is smaller, but the load time is longer because the kernel decompresses the file as it loads it into RAM.
You can find the exact size of compressed and uncompressed files by using Viewbin with the –o command-line option. As we discussed earlier in this article, the report generated by Viewbin –o lists details for modules and files. The modules are listed first; the file information is at the bottom of the report. There is one line for each file. The fourth column in the line shows the size of compressed files (an entry of 0 indicates that the file was uncompressed). The fifth column shows the uncompressed size of all of the files. The following is an example of some file details in the Viewbin –o report.
In the preceding excerpt, wince.nls, tahoma.ttf, and menusel.wav are uncompressed. The other files are compressed. For example, the compressed size of ceconfig.h is 5,598 bytes. Before compression, it was 25,481 bytes (this is the size that you will see in the flat release directory).
Analyze the configuration of the OS
In addition to examining the module and file sizes in ROM, you should examine the configuration of your OS to ensure that you only include the features that you need. By “configuration” we mean the set of catalog items that your OS includes. Each catalog item is associated with a Sysgen variable. When you select a catalog item in Platform Builder, you are pulling in the code required by the associated Sysgen. Some catalog items depend on other catalog items to be included for the feature to work properly. When you select a catalog item in Platform Builder, Platform Builder automatically pulls in the catalog items that the item you selected depends on. You cannot deselect the dependencies unless you deselect the original catalog item.
Find dependencies
To find the dependencies of a catalog item in Platform Builder, right-click a catalog item and then click either Reasons for Inclusion of Item or Show Dependencies. In Windows Explorer, you can also browse the batch files in %_WINCEROOT%\public\CEBase\oak\misc. During OS design and build time, Platform Builder uses these batch files to resolve dependencies. You can examine them to get an idea of the Sysgens that are pulled in by other Sysgens. For example, in winceos.bat, you can see that the Bluetooth Personal Area Networking (SYSGEN_BTH_PAN) catalog item requires the Network Driver Architecture (SYSGEN_NDIS) and the Bluetooth Stack with Universal Loadable Driver (SYSGEN_BTH) as shown in the following lines.
Obtain a complete module list
To see the final group of modules that are included in your OS, you can look at ceconfig.h. This file, which is in the flat release directory, contains a #define for each module that is included in the OS. For example, if you include the Silverlight for Windows Embedded catalog item in your OS, some of the modules listed in ceconfig.h will be:
What’s next?
If you are interested in the ROM footprint of your OS, then you may also be interested in tips that will help you reduce its size. That is the subject of the next article, Tips on Optimizing the ROM Footprint of Your OS, which is also based on Johnson Shih’s video on Controlling ROM Size.
Community Resources
See Also
- Why Has My OS Size Grown?
- Tips on Optimizing the ROM Footprint of Your OS
- Windows Embedded Compact Wiki