Nicolas Besson - Microsoft Windows Embedded CE 6.0 Exam Preparation Kit

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-5Core OS components that depend on the display item

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

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

The following listing illustrates how to use a Project.dat file to create two new root directories named Program Files and My Documents, create a My Projects subdirectory under Program Files, and map the Myfile.doc file from the Windows directory into the My Documents directory.

Root:-Directory("Program Files")

Root:-Directory("My Documents")

Directory("\Program Files"):-Directory("My Projects")

Directory("\My Documents"):-File("MyFile.doc", "\Windows\Myfile.doc")

A thorough understanding of the build system can help to decrease development time and therefore project costs. You must know the steps performed during each phase of the build process if you want to test source code changes quickly and without unnecessary compilation cycles. You must also know the purpose and location of the run-time image configuration files, such as .reg, .bib, .db, and .dat files, to create and maintain OS designs efficiently.

The Windows Embedded CE build system combines the various .reg, .bib, .db, and .dat files during the Make Run-time Image phase into consolidated files that the build system then uses to configure the final run-time image. It is a good idea to check these files if you want to verify that a specific setting or file made it into the final image without having to load the run-time image on the target device. You can find the various run-time image configuration files in the release directory of the OS design. If you discover that expected entries are missing, check the conditional statements and the environment variables and SYSGEN variables defined in your catalog items.

The build system creates the following run-time image configuration files during the Make Run-time Image phase:

■ Reginit.iniCombines the Platform.reg, Project.reg, Common.reg, IE.reg, Wceapps.reg, and Wceshell.reg files.

■ Ce.bibCombines the Config.bib, Platform.bib, Project.bib, and Subproject bib files.

■ Initdb.iniCombines the Common.db, Platform.db, and Project.db files.

■ Initobj.datCombines the Common.dat, Platform.dat, and Project.dat files.

In addition to run-time image configuration files, Windows Embedded CE also uses build configuration files to compile and link source code into functional binary components. Specifically, the build system relies on three types of source code configuration files: Dirs, Sources, and Makefile. These files provide the Build tool (Build.exe) and the compiler and linker (Nmake.exe) with information about the source-code directories to traverse, the source code files to compile, and what type of binary components to build. As a CE developer, you frequently must edit these files, such as when cloning public catalog items, by following the procedures discussed in Chapter 1.