; @XIPREGION IF DEFAULT_DEVICEEMULATOR_REG
IF BSP_NOPCCARD !
#include '$(_TARGETPLATROOT)srcdriverspccardpcc_smdk2410.reg'
#include '$(DRIVERS_DIR)pccardmddpcc_serv.reg'
[HKEY_LOCAL_MACHINEDri versPCCARDPCMCIATEMPLATEPCMCIA]
'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.
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', 'WindowsMyfile.doc')
Lesson Summary
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.ini Combines the Platform.reg, Project.reg, Common.reg, IE.reg, Wceapps.reg, and Wceshell.reg files.
¦ Ce.bib Combines the Config.bib, Platform.bib, Project.bib, and Subproject bib files.
¦ Initdb.ini Combines the Common.db, Platform.db, and Project.db files.
¦ Initobj.dat Combines the Common.dat, Platform.dat, and Project.dat files.
Lesson 2: Editing Build Configuration 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.
After this lesson, you will be able to:
¦ Identify the source code configuration files used during the build process.
¦ Edit build configuration files to generate applications, DLLs, and static libraries.
¦ Estimated lesson time: 25 minutes.
