One of the questions that’s come up in the Windows Embedded Student Challenge is what REG, DAT, BIB, and DB files are, and how CEC files are contstructed.

 

CEC Files and how to include files into your O/S image with Windows CE 4.2 or Windows CE 5.0 are described here – plus a link to the useful CEWSDLGen tool.

 

Here’s an overview of what the REG, DB, DAT, and BIB files do for you – note that including an applicaiton or files into an O/S image can be handled by the CEWSDLGen tool.

 

REG Files

 

REG files for the Windows CE build process use almost the same format as REG files for the other Windows versions. The primary difference is that the REG version marker is removed from the top of the file. This prevents you from accidentally merging a Windows CE REG file into your development workstation's registry, as the default action for double clicking a REG file is normally to merge the data instead of editing the file. (I feel sorry for and am thankful to the first guy that did that and learned the hard way what a problem that would be!) The syntax is fairly straightforward. A key name is specified in brackets based on one of the system-defined keys. Data is assigned to sub-keys using the key name, data type, and data value, with @ identifying the key's default value.

 

[HKEY_LOCAL_MACHINE\SOFTWARE\MegaSoft\KillerApp]

   "Version"=dword:0400

   "Build"=dword:0b3f

   "Greeting"="Howdy!"

   "Messages"=multi_sz:"Windows CE is Cool!","KillerApp is Super Cool!"

   "AppData"=hex:01,00,02,00,03,00

 

In this example, a new key is created for the MegaSoft software company for their KillerApp. The following values are added to that key.

 

Name

Type

Value

Version

REG_DWORD

0x0400. DWORD value types are always in hex and therefore the "0x" prefix is not used.

Build

REG_DWORD

0x0b3f

Greeting

REG_SZ

"Howdy!"

Messages

REG_MULTI_SZ

"Windows CE is Cool!\0KillerApp is Super Cool!\0\0"

AppData

REG_BINARY

01,00,02,00,03,00 Hex is always assumed here as well.

 

DAT files

 

DAT files are used to specify how the file system should initialize the RAM file system structure when the system is cold booted. You can create a complete file system structure in the RAM system to meet your application and end-user needs. The file system will copy any files specified in the initobj.dat file into the folders they are listed for. Keep in mind that all ROM files exist in the \Windows\ folder already, so copying EXE and DLL files to RAM-based folders in a DAT file just wastes space. Instead, you should create a shortcut file to reference the EXE in the windows folder.

 

The syntax for a DAT file is a bit odd but not complicated:

 

root:-Directory("Program Files")

Directory("\Program Files"):-Directory("KillerApp")

Directory("\Program Files\KillerApp"):-File("KillerApp.lnk","\Windows\KillerApp.lnk")

 

This sample creates the Program Files folder off of the root of the file system. Inside that folder, it creates a new one called KillerApp, and lastly it copies the KillerApp shortcut (.LNK file) to the newly created folder. The user can now navigate to Program Files\KillerApp and click on the shortcut to start the application.

 

DB files

 

DB files define the default RAM-based property database for the object store. The syntax is a bit cryptic, but it is documented. For Platform Builder-generated systems, it is rare to need to use the database at all, except to set up the automatic connection for ActiveSynch, as follows:

 

; This is the database initialization file.

; format is as follows -

; Database : <db name> : <type in hex> : <num sort order> : <hex propid> : <hex flags> ....

;    CEDB_SORT_DESCENDING         0x00000001

;    CEDB_SORT_CASEINSENSITIVE    0x00000002

;    CEDB_SORT_UNKNOWNFIRST       0x00000004

;    CEDB_SORT_GENERICORDER       0x00000008

; A database specifier can be followed by any number of record specifiers

; Record :

; A record specifier can be followed by any number of field specifiers

; Field : <hex propid> : <value> [ either string or hex dword ]

; End   (ends a matching database or a record context)

 

Database: "DB_notify_events" : 0 : 1 : 0001001F : 0

; 0001001F - PROPIDR_NAME

; 0002001F - PROPIDR_CMDLINE

; 00030013 - PROPIDR_EVENT

Record :

Field : 0001001F : "repllog.exe"

Field : 0002001F : "AppRunAtRs232Detect"

Field : 00030013 : 9

End

End Database

 

This DB file will set up the notification database to run REPLLOG whenever an RS232 event is triggered. This will start the connection process on the default "hot plug" port for ActiveSync.

 

BIB files

 

ROMIMAGE uses Binary Image Builder (BIB) files to configure how it should configure the ROM. BIB files are just plain text files with keywords defining four different sections.

 

The modules section is identified with the keyword MODULES on a line of its own. In the modules section, executable modules are listed for code that will execute in place (XIP). The files section (keyword FILES) lists other files to place in the image (bitmaps, data files, HTML pages, and so on). It can also specify executable modules not intended for XIP. Rarely used diagnostic applications are a good candidate for that. The items in the files section are compressed by default to reduce the size.

 

The syntax is pretty straightforward for the entries of the modules and files sections:

 

<Target Name> <Whitespace> <Workstation path> <memory Section> <flags>

 

<Target Name> is the name of the file as it will appear in the ROM. <Workstation path> is the path ROMIMAGE will use to find the actual file (normally based on $(_FLATRELEASEDIR)). The memory section will be "NK" with few exceptions. (Boot loaders are a common exception).

The flags are summarized in the following table:

 

Flag

Purpose

C

Compressed (default for files section)

U

Uncompressed (default for modules section)

R

Compress resources only

H

Hidden file

S

System file

 

The remaining two sections of BIB files are normally placed in the Config.bib file (merged with the other BIB files in the makeimg phase to generate ce.bib). These are:

 

 The memory section, which describes the memory layout for your system. It's syntax is as follows:

                        <name> <Virtual Address> <Size> <TYPE>

 

where TYPE is one of the following:

 

Value

Description

RAM

Specifies a region of RAM available to running processes and the RAM-based Windows CE file system. The region must be contiguous.

RAMIMAGE

Specifies that the region should be treated like ROM. The kernel copies all writeable sections for an application into RAM and fixes the memory addresses prior to starting the application process.

RESERVED

Specifies that a region of RAM is reserved. Currently, Romimage.exe ignores this field, so it functions only as a comment. This memory might be a video frame buffer or a direct memory access (DMA) buffer. Do not overlap reserved regions with other memory regions. Windows CE .NET provides a means of allocating such buffers programmatically, so the use of reserved is now effectively obsolete.

 

The config section specifies a number of miscellaneous settings, including the size and width of ROM if you are using the raw binary image format (ABX=ON).

 

– Mike