| Understanding Windows CE 5.0's configuration file formats |
by Mike Hall (May 24, 2005)
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.
Understanding Windows CE 5.0's configuration file formats
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 | R EG_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, 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).
 About the Author: Mike Hall is Technical Product Manager on the Microsoft Windows CE team. Among other things, he writes an extensive (and often entertaining) blog that's published on Microsoft's MSDN developer website.
(Click here for further information)
|
|
|
7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.
4 Legal Reasons to Control Internet Access
The Internet is obviously a valuable resource for many organizations. However, many are exposed to legal liability concerns because they fail to control Internet access. Learn if you're safe in this white paper.
Rapidly Resolve J2EE Application Problems
Whether you are in the process of building J2EE applications or have J2EE applications already running in production, you must ensure that they deliver the expected ROI. Learn how in this white paper.
Load Testing 2.0 for Web 2.0
There are many unknowns in stress testing Web 2.0 applications. Find out how to test the performance of Web 2.0 in this white paper.
Build Better Games Online
For the game infrastructure providers, life is complex. Making money from games has become more complicated. Why? Find out in this white paper.
Building a Virtual Infrastructure from Servers to Storage
This white paper discusses the virtual storage solutions that reduce cost, increase storage utilization, and address the challenges of backing up and restoring Server environments.
Gaining Faster Wireless Connections with WiMAX
Welcome to what is quickly becoming the hyperconnected world where anything that would benefit from being connected to the network will be connected. Learn more in this white paper.
Is Your Desktop a Security Threat?
The new wave of sophisticated crimeware not only targets specific companies, but also targets desktops and laptops as backdoor entryways into those business’ operations and resources. Learn how to stay safe in this white paper.
Increasing SAN Reliability by 100 Percent
Storage area networks (SAN) are a strong part of storage plans. Learn how to increase your reliability and uptime by 100 percent in this case study.
|
|
|
|
|
Use of this site is governed by our Terms of
Service and Privacy Policy.
Except where otherwise specified, the contents of this site are copyright © 1999-2008
Ziff Davis Enterprise Holdings Inc. All Rights Reserved.
Reproduction in whole or in part in any form or medium without express written permission of Ziff Davis Enterprise is
prohibited. Windows is a trademark or registered trademark of Microsoft Corporation in the United States and/or other countries and is used by WindowsForDevices under license from owner. All other marks are the property of their respective owners. WindowsForDevices is an independent publication not affiliated with Microsoft Corporation.
news feed