When you design a Windows Embedded Compact 7 OS for a device that has limited ROM, the size of the OS footprint in ROM is particularly important. You can calculate the size of the OS and its individual modules and files by using the techniques described in the article How to Analyze OS ROM Size, which is based on Johnson Shih’s video on Controlling ROM Size.
This article, which is also based on Johnson Shih’s video, provides tips on how to reduce the OS size by using two approaches: working with modules and working with Sysgens. Because there is a trade-off between OS ROM size, RAM consumption, and performance, this article covers ways to offset impacts on RAM and performance that may result from a reduction in ROM size. This article includes information on how to:
During the build process, Make Binary Image tool (MakeImg.exe) uses a number of Binary Image Builder (.bib) Files to determine which modules and files to include in the OS image and where to place these components within ROM. The MODULES and FILES sections of the .bib files are of most interest to us. For more information on these sections, see the companion article How to Analyze OS ROM Size. During the build process, all of the .bib files are merged into the ce.bib file, which is in your flat release directory. Because all of the files that are listed under MODULES and FILES in ce.bib are pulled into nk.bin, ce.bib provides a good place for you to start your investigation on what is in ROM.
It is important that you select the most appropriate section (MODULES or FILES) for your code and data because this choice affects the trade-off between ROM usage, RAM consumption, and performance. In brief, put native code executables in the MODULES section, and put non-executables such as data, resource DLLs, managed code, audio, and bitmap files in the FILES section.
Makeimg strips off extra information from executables in the MODULES section and fixes up the modules in ROM, so put your executables in the MODULES section. (It would not make sense to put non-executables under MODULES because Makeimg can’t fix them up.) When you put your executables under the MODULES section, you improve your system because:
By default, files in the FILES section are compressed, but you can choose to leave them uncompressed. To leave a file uncompressed, give the file a U attribute in its .bib file. You need to be aware of the advantages and disadvantages when you use compression. Consider the following:
Note that managed code is considered non-executable because it is not native code, so Makeimg can’t fix it up. Therefore, put managed code in the FILES section. For example, .NET DLL looks like an executable, but it’s not. Put it under FILES.
You can review your non-executable files to see if you have an opportunity to save space. Here are some tips:
You may be able to rework some of your executables (that is, the modules that you put in the MODULES section of your .bib files) to save some space in ROM. This task can be difficult to do for stability reasons. It may involve making big changes in executables, so you have to do a lot of testing. You may want to consider the following suggestions for reworking executables:
DUMPBIN /HEADERS <your module>
Catalog items are associated with Sysgen variables. When you select a catalog item in Platform Builder, you increase ROM size because you are pulling in the code for the selected Sysgen and any Sysgens that it depends on. Here are some steps that you can take to minimize the number of Sysgens that you use:
OS ROM size, memory usage, and performance are related. When you reduce the ROM footprint, RAM consumption may increase and the speed of the system may be negatively affected. To reduce these impacts, you can enable file caching and tune the paging pool as explained in the following sections.
When you use file compression, the OS needs to decompress the file before it uses it, which takes time. You can reduce the impact on performance by enabling file caching. When you use file caching, the OS decompresses the file only once and then keeps the content in RAM. To enable file caching, see Registry Settings for File Caching.
You can use the paging pool to limit the amount of memory that each module can consume. There are two paging pools: the loader pool, which is for read-only files such as executable code and read-only data, and the file pool, which is for read-write data such as file-backed memory-mapped files and the file cache filter. For information on how the paging pool works, see the article Paging and the Windows CE Paging Pool.
In Windows CE 5.0, the paging pool was off by default. In Windows Embedded CE 6.0 and Windows Embedded Compact 7, it is on by default. First consider whether you need to use the paging pool at all. The decision depends on whether your OS uses XIP. If your OS uses XIP, you may be able to turn the paging pool off or use a smaller paging pool size because XIP does not use RAM.
When the paging pool is too small, pages are frequently paged out and then paged in again. This is called thrashing. When the paging pool size is too high, you are reserving RAM that might not be used. You need to find a balance. To choose the correct pool size, be aware that the following scenarios can affect RAM usage differently:
After you have identified your important scenarios, you can do the following:
The default size of the loader pool and the file pool is 3 MB and 1 MB, respectively. There are two ways to set the paging pool size. You can set it during the Makeimg build stage, or you can change it at run time. Information on both methods follows.
The following is a check-list for you to review as you try to reduce OS ROM size.
Keep this list handy!