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