理解wince的配置文件格式。Understanding Windows CE 5.0's configuration file formats

Foreword: A variety of configuration parameters are required to fully specify a Windows CE system. This information is contained within a number of text files of various types. In particular, .REG, .DB, .DAT, and .BIB files serve to define and configure a Windows CE system.

Mike Hall, a technical product manager on Microsoft's Windows CE team, puts these files in context and describes their syntax in this brief technical article.

---

理解wince的配置文件格式。其实和WINCE6.0类似。

这些文件可以在在VS.net 2005里面可以查看

Understanding Windows CE 5.0's configuration file formats
REG Files  （注册表文件）

 

注册表文件：这个文件和windows平台下的文件使用方法一样，具体操作方式很多。

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	R EG_BINARY	01,00,02,00,03,00 Hex is always assumed here as well.

DAT files

 

DAT文件主要用于初始化RAM文件系统结构。主要是当系统冷启动后，RAM初始化部分。

DAT文件看起来非常怪，但是好好分析一下还是可以理解的。

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, and the config section.

The memory section, which describes the memory layout for your system, has the following syntax:

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