MODULES Section
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
The MODULES section specifies which Windows Embedded CE-based modules are included in the run-time image, and how they are loaded into the memory table as established in the MEMORY section of the Config.bib file.
This section can contain up to 2,000 modules, which consist of a two-part combination of source code and data.
Note
Do not include managed code in the MODULES section. This is because the kernel does not load managed code. Instead, managed code is opened as a memory-mapped file by the .NET Compact Framework. Managed code must be included in the FILES section. For more information, see FILES Section.
The following code example shows the columnar format used by a MODULES section entry.
Name Path Memory block Section override Type
Parameters
- Name
This parameter specifies the name of the MODULES section entry as it appears in the memory table. Usually, the Name entry is the same as the name of the file referenced by Path.
- Path
This parameter specifies the full path to the file, as specified in the MODULES section that Romimage.exe incorporates into the run-time image. Usually, the Path file name is the same as the Name ** MODULES section entry.
Memory block
This parameter specifies the RAMIMAGE section of the memory region into which Romimage.exe loads the object module.Romimage.exe places the object modules in the specified memory location in the order in which they appear in the MEMORY section. This memory location corresponds to the MEMORY section defined in the Config.bib file.
There is only one RAMIMAGE per run-time image. The name used to specify the MEMORY section must be the same as the name specified in the Config.bib file.
Section override
This parameter specifies what type of section entry Romimage.exe treats the entry as, and can be set to the following flags:- MODULE to define it as a MODULES section entry
- FILES to define it as a FILES section entry
When this is added to an entry, Romimage.exe ignores the section that the entry resides in, and treats the entry as a member of the specified section.
This is optional.
Type
This parameter specifies the file type and can be a combination of the following:- S to define it as a system file.
- H to define it as a hidden file.
- R to compress resources. Applies to the MODULES section only.
- C to compress everything if applied to a module.
If a file is compressed, the kernel uncompresses, performs run-time fixups, and demand pages the image into RAM.
If the compressed file is in RAM due to the RAMIMAGE section mapping to RAM, this results in the file occupying two RAM areas. However, the compressed image can reside in flash memory. For more information about compression, see COMPRESSION.
If this flag is set, it takes precedence over other settings. - D to prevent a debugger from running.
- N to mark a module as nontrusted. Applies to the MODULES section only.
- P to signal that Romimage.exe must not check the CPU type specified in the header against the run-time image's target CPU type on a per-module basis. This flag is usually used for resource-only DLLs that can be built on one CPU type and used on different CPU types.
- K to signal that Romimage.exe must fixup the module to a kernel address.
In this process, Romimage.exe assigns a fixed virtual address to the public exports that the DLL provides and which is identical for all programs that use the DLL. A module that has this flag set can only be loaded with LoadKernelLibrary.
Applies to the MODULES section only. - X to signal that Romimage.exe must sign the module and include the signature file in the ROM, which helps determine whether a run-time image is valid.
Applies to the MODULES section only. - M to signal that the kernel must not demand page the module. By default, the kernel demand pages modules as needed. This flag is usually set for system services that are called in paging, or which are in out-of-memory (OOM) condition.
Applies to the MODULES section only. - L to signal Romimage.exe to not split a ROM DLL between the process virtual memory area and the process slot 1. This protects DLLs that require the code and data to reside at consecutive virtual addresses.
Applies to the MODULES section only. - U to keep a specific file or both sections of a module uncompressed, unless the C flag is set.
Example
The following code example shows an entry in the MODULES section.
INIT.EXE %_WINCEROOT%\RELEASE\INIT.EXE NK SH
MYDLL.DLL %_WINCEROOT%\RELEASE\MYDLL.DLL NK SHC
Remarks
In this example, the entries tell Romimage.exe to include Init.exe and Mydll.dll in the run-time image, in the section labeled NK.
The C flag in the second MODULES section entry also specifies that Romimage.exe needs to compress Mydll.dll.
The S and H flags on both files indicate that these are system and hidden files.
Remarks
By default, all modules are uncompressed.
The R and C types refer to how the file is stored in ROM and how much RAM is used when the file is run.
For example, variables are always compressed into ROM because they must be copied into RAM to run. However, code does not need to be compressed because it can run directly in ROM.
When deciding these attributes, remember that as you increase the compression you need less ROM but more RAM.
The D type prevents a debugger from running while the module is loaded and prevents a debugger from loading the module to debug it.
The N type marks a module as nontrusted because by default every module in the ROM MODULES section of a .bib file and the resulting binary is considered to be a trusted application. This is better than putting the module in the FILES section of the .bib file because it keeps the XIP capabilities.
The K type signals that a module is to be treated like the kernel for memory location and relocation fixup styles. The module must also be loaded with a special LoadKernelLibrary instead of in the usual manner. This is currently only used for the debugger and Remote Kernel Tracker.