Share via

MODULES Section

  • Article

The MODULES section specifies how the Windows CE-based modules 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.

Each MODULES section entry has the following columnar format.

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 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 OS 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.

    • D to prevent a debugger from running.

    • N to mark a module as non-trusted. Applies to the MODULES section only.

    • P to signal that ROMIMAGE must not check the CPU type specified in the header against the platform'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 must fixup the module to a kernel address.

      In this process, ROMIMAGE 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 has to sign the module and include the signature file in the ROM, which helps determine whether an image is valid.

      Applies to the MODULES section only.

    • M to signal the kernel to page in the whole module. By default, the kernel demand pages modules as needed. This flag is usually set for system services that will be called in paging, or which are in out-of-memory (OOM) condition.

      Applies to the MODULES section only.

    • L to signal the ROMIMAGE 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 the module uncompressed, regardless of what the default setting is.

Example

MODULES 
  INIT.EXE  %_WINCEROOT%\RELEASE\INIT.EXE  NK  SH 
   nk.exe          $(_FLATRELEASEDIR)\kitlnokd.exe             NK  SHD
   nk.exe          $(_FLATRELEASEDIR)\kitlnokd.exe             NK  SHN

Romimage.exe loads the Init.exe object module into the NK memory block. Romimage.exe creates Init.exe from %_WINCEROOT%\Release\Init.exe. The object module is both a system file (S) and a hidden file (H).

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 in order to run.

However, code does not need to be compressed because it can run directly in ROM. When deciding these attributes, remember that the more you compress, the smaller the ROM, but the more RAM will be needed.

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 non-trusted, as 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 with regards to memory location and relocation fixup styles. The module also has to be loaded with a special LoadKernelLibrary instead of in the usual manner. This is currently only used for the debugger and Remote Kernel Tracker.

 Last updated on Friday, October 08, 2004

© 1992-2003 Microsoft Corporation. All rights reserved.