Table 2-3 File type definitions for MODULES and FILES sections
| MODULES and FILES Sections | MODULES Section Only |
|---|---|
| ■ S The file is a system file. | ■ K Instructs Romimage.exe to assign a fixed virtual address to the DLL's public exports and runs the module in kernel mode rather than user mode. Drivers must run in kernel mode to have direct access to the underlying hardware. |
| ■ H The file is hidden. | ■ R Compress resource files. |
| ■ U The file is uncompressed. (The default setting for files is compressed.) | ■ C Compress all data in the file. If the file is already in RAM, it will be decompressed again into a new section of RAM, which results in higher RAM consumption. |
| ■ N The module is not trusted. | ■ P Do not check the CPU type on a per-module basis. |
| ■ D The module cannot be debugged. | ■ X Sign the module and include the signature in the ROM. |
| ■ M Signals that the kernel must not page the module on demand. (See Chapter 3 for more information on the effects of demand paging.) | |
| ■ L Instructs Romimage.exe not to split the ROM DLL. |
Conditional .bib File Processing It is important to note that .bib files support conditional statements based on environment variables and SYSGEN variables. You can set environment variables through catalog items, and then check these variables in IF statements in a .bib file to include or exclude certain modules or other files. For SYSGEN variables, use @CESYSGEN IF statements instead.
The MODULES and FILES listing in the previous section illustrates the use of @CESYSGEN IF and IF statements for processing conditions based on SYSGEN and environment variables. For example, the @CESYSGEN IF CE_MODULES_DISPLAY statement in the MODULES sections specifies that the BSP should automatically include the display driver if the OS design includes a display component. You can verify that Platform Builder adds the display component to the BSP automatically if you display the Catalog Items View in Visual Studio for an OS design that uses a display, as illustrated in Figure 2-5.
Figure 2-5 Core OS components that depend on the display item
Registry Files
Registry (.reg) files are used to initialize the system registry on the remote device. These files are almost identical to registry files of Windows desktop operating systems, except that the CE .reg files do not start with a header and version information. If you accidentally double-click a CE .reg file on your development computer and confirm that you want to add the settings to the desktop registry, a dialog box appears to inform you that the .reg file is not a valid registry script. Another difference is that CE .reg files can include conditional statements similar to .bib files, so that you can import registry settings according to the selected catalog items. The following snippet from the Platform.reg file of the Device Emulator BSP illustrates the use of preprocessing conditions.
; Our variables
#define BUILTIN_ROOT HKEY_LOCAL_MACHINE\Drivers\BuiltIn
;#define PCI_BUS_ROOT $(BUILTIN_ROOT)\PCI
#define DRIVERS_DIR $(_PUBLICROOT)\common\oak\drivers
; @CESYSGEN IF CE_MODULES_RAMFMD
; @CESYSGEN IF FILESYS_FSREGHIVE
; HIVE BOOT SECTION
[HKEY_LOCAL_MACHINE\init\BootVars]
"Flags"=dword:1 ; see comment in common.reg
; END HIVE BOOT SECTION
; @CESYSGEN ENDIF FILESYS_FSREGHIVE
; @CESYSGEN IF CE_MODULES_PCCARD
; @XIPREGION IF DEFAULT_DEVICEEMULATOR_REG
IF BSP_NOPCCARD !
#include "$(_TARGETPLATROOT)\src\drivers\pccard\pcc_smdk2410.reg"
#include "$(DRIVERS_DIR)\pccard\mdd\pcc_serv.reg"
[HKEY_LOCAL_MACHINE\Dri vers\PCCARD\PCMCIA\TEMPLATE\PCMCIA]
"Dll"="pcmcia.dll"
"NoConfig"=dword:1
"NoISR"=dword:1 ; Do not load any ISR.
"IClass"=multi_sz:"{6BEAB08A-8914-42fd-B33F-61968B9AAB32}=
PCMCIA Card Services"
ENDIF ; BSP_NOPCCARD !
; @XIPREGION ENDIF DEFAULT_DEVICEEMULATOR_REG
; @CESYSGEN ENDIF CE_MODULES_PCCARD
Database Files
Windows Embedded CE relies on database (.db) files to set up the default object store. The object store is a transaction-based storage mechanism. In other words, it is a repository for databases in RAM that operating system and applications can use for persistent data storage. For example, the operating system uses the object store to manage the stack and memory heap, to compress and decompress files, and to integrate ROM-based applications and RAM-based data. The transaction-oriented nature of the storage mechanism ensures data integrity even in the event of a sudden power loss while data is being written to the object store. When the system restarts, Windows Embedded CE either completes the pending transaction, or reverts to the last known good configuration prior to the interruption. For system files, the last known good configuration can mean that Windows Embedded CE must reload the initial settings from ROM.
File System Files
File system (.dat) files, specifically Platform.dat and Project.dat, contain settings to initialize the RAM file system. When you cold start the run-time image on a target device, Filesys.exe processes these .dat files to create the RAM file system directories, files, and links on the target device. The Platform.dat file is typically used for hardware-related entries while the Project.dat file applies to the OS design, yet you can use any existing .dat file to define file system settings because the build system eventually merges all .dat files into one file named Initobj.dat.
For example, by customizing the Project.dat file, you can define root directories in addition to the Windows directory for a run-time image. By default, items placed in the ROM image appear in the Windows directory, yet by using a .dat file, you can make files also appear outside the Windows directory. You can also copy or link to files in the ROM Windows directory. This is particularly useful if you want to place shortcuts on the desktop or add links to your applications to the Start menu. Similar to .reg and .bib files, you can use IF and IF ! (if not) conditional blocks in .dat files.