Windows CE: Inside the Build System

  • Article

 

Mike Hall
Microsoft Corporation

Steve Maillet
Entelechy Consulting

In this article we will take a look at the tool used to build a custom image of the Microsoft® Windows® CE operating system, appropriately called Platform Builder. Microsoft Windows CE Platform Builder ships with the Windows CE .NET product, and is an integral part of the FREE Web download of Windows CE .NET Beta 2 Emulation Edition. This can be downloaded from https://www.microsoft.com/windows/Embedded/ce/taliskerpreview/default.asp#getthebeta.

The downloadable version of Windows CE .NET Beta 2 Emulation Edition supports one Board Support Package (BSP), this being an emulator. Both the Platform Builder tool and emulator run on Microsoft® Windows® XP (or Windows NT/Windows 2000) desktop—more on the emulator later in this article. We will also take an under-the-covers look at the Windows CE build system.

All screenshots and steps outlined in this article pertain to the Windows CE .NET Beta 2 Emulation Edition. Please note that this is a pre-release version of the product; screen UI and functionality may change between the download version and the final product.

Okay. Let's dig into configuring, building, and downloading an operating system image to emulation. Once we've been through this process, we can then take a look at what's happening behind the scenes.

Deploying an image of Windows CE can be broken into three distinct steps:

  1. Configure
  2. Build
  3. Download

Step 1. Configuring a Windows CE Image

First a quick bit of history. Previous versions of Windows CE have shipped with a number of pre-configured platform workspaces. These could be considered the starting point for your project. They were named minkern, mininput, mincomm, mingdi, minwmgr, minshell, maxall, iesample, dxmax (a total of nine configurations for Windows CE 3.0), minkern being the smallest build and maxall being the largest (400 KB through to 8 MB respectively). For a description of the features contained in each of the workspaces, take a look at Microsoft Windows CE 3.0 Operating System Configurations.

With these, it was sometimes hard to determine the best starting point for a project, and sometimes harder still to customize a platform to exactly meet developers' needs. This has now changed with Windows CE .NET. The new Platform Builder IDE supports a range of device images—Web Pad, Internet Appliance, Residential Gateway, Set-Top-Box, and others—and a Custom Image configuration. This makes configuring the operating system image a snap.

Let's take a look at the New Platform Wizard, which can be found in Platform Builder by selecting File, and then New.... This is a seven-step wizard.

Step 1. This provides an outline of the steps that follow: We will need to select a "board support package" (a reference platform; for the Web download version, this will be Emulator), a platform configuration (Web Pad, Internet Appliance, and so on), a configuration variant (Basic Web Pad, Enterprise Web Pad, and so on), and add any additional configuration (networking, for example).

Figure 1. Welcome to the Platform Wizard

Step 2. This is where we select the platform configuration. You can choose from a number of device configurations. In this case, I've elected to use the Web Pad configuration, and have chosen the name MyPad. Note that choosing one of these configurations provides the base components for your platform. We can then add or remove features using the platform workspace and the catalog.

Figure 2. Select a base configuration

Step 3. Which reference platform(s) are you working with? (The Web download of Platform Builder only supports emulation.) Note that the release version of Windows CE .NET will support a range of hardware reference platforms, and this list can be further extended through third-party add-in components.

Figure 3. Select one or more reference platforms

The platform workspace will be created in C:\WINCE400\PUBLIC\MyPad. Now is probably a good time to introduce some of the folders used by the Windows CE build system.

If we were to examine the C:\WINCE400 folder, we would notice a number of sub-folders. Three of these are of particular interest:

C:\WINCE400\PLATFORM. This contains hardware-specific files, and Board Support files. You will typically find one folder per hardware platform listed under the Platform folder (that is, Geode, CEPC, Emulator, and so on). Note that with Windows CE .NET, we've taken a number of platform-independent drivers and moved these from the platform folder to a common folder: C:\Wince400\public\common\oak\drivers. You can take a look at the drivers that are located under this folder.

C:\WINCE400\PUBLIC. This contains each of our workstation configurations (in our case, MyPad) and the components that make up each of the available starting configurations.

C:\WINCE400\PRIVATE. This folder contains Windows CE source code (for the Kernel and other components). Source doesn't ship with the emulation download, but is available as a Web download for Windows CE 3.0, and will also be available for Windows CE .NET.

Step 4. We've already chosen the Web Pad. Now we need to decide which flavor of Web Pad meets our requirements. In our case, we only need the Handheld PC-like shell, and Microsoft® Internet Explorer (based on Internet Explorer 5.5). The Enterprise Web Pad configuration adds support for Microsoft® Messaging Queue (MSMQ), Terminal Services Client (remote desktop), and additional enterprise features. Even though we've selected the basic Web Pad in our example, we can add features such as MSMQ and Terminal Services Client from the catalog at any time to fully customize our platform.

Figure 4. Select a 'flavor' of WebPad

Step 5. We select which applications and media components to add to our platform. (By default, the Windows Media components are selected; I've disabled them from my build). Once we've configured the platform, we can then add our own applications and services using the Project Wizard (which can also be used to add files to a project).

Figure 5. Select application and media components

Step 6. Here we select the networking and communication options for our platform, including the support for Bluetooth, Point-to-Point Tunneling Protocol (PPTP), and Voice over IP (VoIP). Again, these are options we can select from the catalog at any time during our platform development. The wizard makes the initial configuration of our platform easy.

Figure 6. Select networking and communication features

Step 7. This step simply confirms our settings and launches help files to assist us in further customizing our platform. We can simply hit Finish.

Figure 7. Configuration is complete

At this point, our core platform configuration is complete. We have two options; we can either build as is, or further customize by adding components from the catalog (see below), creating applications, drivers, or function/resource DLLs.

Figure 8. Snapshot of the catalog

Now let's see how easy it is to add an application to our operating system configuration.

Adding an application to the Windows CE .NET operating system image

Select File and then select New Application; this will launch the Application Wizard. Users of Windows CE 3.0 or earlier will recognize the wizard's look and feel, yet there are some simple but extremely useful changes that have taken place in the wizard. Read on to find out more.

The Application Wizard contains two simple steps:

Step 1. Choose what type of application you're building. You have a number of choices; perhaps the most frequently used will be WCE Application (Windows application) and WCE Dynamic Link Library, which can be a device driver, a function library, or a set of resources—in fact, using a Dynamic Link Library to contain localized resources is a neat way to localize an application. (By the way, do let us know if you're interested in an article on Unicode programming, building localized applications, or porting desktop applications to Windows CE.)

In our example, we will choose WCE Application, and name our application "MyApplication." You will notice on the "New" dialog (see Figure 9 below) that the location of the application is in the folder C:\WINCE400\PUBLIC\MyPad\MyApplication—new applications are created in a subfolder of our workspace.

Figure 9. The Application Wizard

Step 2. (or Step 1 of 1) This is where we choose what type of application to build. We could start with an empty project and insert source code from a previous application. We could also choose to start with a "simple" Windows CE application, which simply exposes the default Windows application entry point "WinMain" (we're responsible for writing everything else). Or we can start with a typical HelloWorld application, a fully featured graphical application, containing support for keyboard and mouse and drawing code to maintain the Windows client area. Though it is our responsibility to add whatever additional code is required for our custom application, this does provide a great starting point for our application.

Figure 10. Choose an application type

Once we've added our application to the workspace, this will appear as a "user feature" in our workspace (see below).

Figure 11. Our workspace, including the application

The workspace (above) contains two tabs, the first being the FeatureView, which contains a list of features or components that make up our platform. The second tab, ParameterView, displays our platform registry, Binary Image Builder (BIB) files (more on this later), database files, and DAT files (used to create folders and shortcuts).

Ok, so what about the extremely useful changes that have taken place between Windows CE 3.0 and Windows CE .NET? By default (in Windows CE 3.0), an application that appeared in the workspace would get built, but would not be included in the final image of the operating system (you would need to modify your Project.bib file to include the application/feature in the operating system). With Windows CE .NET, every user feature is automatically included in the final build. You have control over a number of settings for each feature, including whether the feature is hidden. To control this, select Platform, select Settings, select the user feature from a list of available components, and then select BIB Info (see below).

Figure 12. "User features" configuration

Step 2. Building the Windows CE Image

So we now have a configured workspace containing the components of a basic Web Pad, as well as our HelloWorld application. We have two choices for building an application: Debug and Release. Each build is generated into its own build output folder. In our case, using the MyPad example, the following folders would be created and populated during the build process:

Release: C:\WINCE400\PUBLIC\MyPad\RelDir\EMULATOR_X86Release

Debug: C:\WINCE400\PUBLIC\MyPad\RelDir\EMULATOR_X86Debug

Of course, if I were using the released version of Windows CE .NET, I could also build for additional BSPs using the same project workspace. Building to individual folders for Debug and Release gives us control over individual settings. (Say that we want to exclude MyApplication, for example, from the operating system image for our debug build.) This gives us the ability to download an operating system image to our hardware (or emulator), and then run the application from Platform Builder (select Target, then select Run).

This command will examine the build output folder and provide a list of all executable programs (whether included into the final operating system image or not). If the application is not in the operating system image, then it will be pushed down to the target and executed. In any case, here's the cool bit: We can debug the application, locate an error, "kill" the process on the target, make modifications, and then re-download and test—all without having to rebuild the operating system. Of course, we could also do this using Microsoft® eMbedded Visual C++®.

The decision whether to build for Debug or Release (and which platform to build for) is controlled from the build tool bar. The emulation preview download can only build for Emulation Debug and Emulation Release.

Figure 13. The build toolbar

To build the operating system image, simply select Build, then select Build Platform.

We will take a look at the how the build system works later in this article, and then expand on some of this information in next month's article.

Step 3. Downloading the Windows CE Image

Platform Builder supports downloading to devices through Serial/Parallel, Ethernet, and (through add-in components) JTAG/BDM. We need to configure the download and debug transports before being able to download our operating system image. Emulation is a special case since the target is running on the same PC as our development tools.

To configure the download and debug targets, select Target, then select Configure Remote Connection. The following dialog box (see Figure 14) is displayed. Since our only target is emulation, we select Emulator for Download and Kernel Transport.

Figure 14. Configuring remote services

We can alter the configuration of the emulation environment by clicking the Download Configure button. The following settings can be modified.

Video Ability to set the emulator's screen resolution and color depth
Memory The amount of memory the emulator has to work with.
Skin File Not supported on the Web download. We will discuss this at length in another article.
Serial Ports Uses the PC's serial ports.
Ethernet Uses the PC's Ethernet connection.
Parallel Port Uses the PC's parallel port.

Figure 15. Emulation options

So why is emulation interesting to a developer building a Windows CE Image? Actually, there are a number of reasons.

  • Parallel development. One of the key aspects of developing a product (desktop or embedded) is time to market. Without emulation, you are tied into working with a hardware reference platform (which may not match your final hardware configuration), or waiting until your hardware-development team has completed their reference board. Using emulation, your application (and shell) development teams can develop and test their applications in parallel to hardware development.
  • Product testing. Another benefit of using emulation is the ability to ship an operating system image to your customers (or internal testing teams) for them to try out. The release version of Windows CE .NET will ship with an emulator that supports skins and virtual keyboards (more on this in a later article).

Windows CE .NET Build Process

Okay. You've kicked the tires, had it out for a spin around the block, and now it's time to take a closer look under the hood, to see what's really going on when you build an operating system image.

The build process for Windows CE .NET is divided into 4 phases:

CESYSGEN

This phase filters all the header files, DEF files for generating DLLs, and other files used in the build process. This filtering removes parts of the system that you have not selected for the operating system. The processed headers and libraries are used later on to generate a platform-specific SDK.

BSP

The Board Support Package (BSP) phase compiles and links the Graphics, Windowing, and Events Subsystem (GWES), kernel, OEM adaptation layer (OAL), and device drivers. All of these parts are very hardware dependent. The kernel is linked to the OAL to generate nk.exe. GWES is linked with some of the native driver libraries (battery and notification), and the other drivers are compiled and linked to create DLLs. (A future article will focus on the details of what constitutes a good and proper BSP.)

BUILDREL

This phase takes files, data, configuration, and executable modules from a variety of places and copies them into the flat release directory for the Make image stage (see below). When using the IDE, this is also when the projects in your workspace are built and the EXE or DLL is copied to the release directory.

MAKEIMG

As its name implies, this phase will actually generate the final ROM image for the platform. It processes all of the files in the release directory according to the configuration files. Make image will perform a link and locate on all executable modules that will be eXecuted In Place (XIP) in the image.

Directory Structure

Before jumping into the details of each stage, let's take a closer look at the directory structure used in the build.

Figure 16. Directory structure for build

All of the build files and folders are located under the %_WINCEROOT% folder, which is normally set to c:\WINCE400 by the installation. (You can override this to put it anywhere you want, but if you expect to work with others, it's usually easiest to place it at the root of a disk drive so everyone can locate it.) Underneath the root, there are a few directories, two of which are of significant importance. (The other folders are used in the build, but you should really consider them to be untouchable, as they contain Microsoft-provided parts of the build that can and will change from version to version.)

PLATFORM

This folder contains a set of folders. One for each BSP you have installed on your system. The general idea is to separate the hardware-specific files, code, and settings for a particular system from the parts of the system that are agnostic towards the hardware. This allows you to have a single workspace that supports multiple hardware platforms. This is most useful when one of the BSPs is for emulation, for it allows you to build an exact version of the operating system that will exist on your real hardware, and it will run on the emulator before the hardware design is even completed.

PUBLIC

This folder is where all the Microsoft-provided configuration information is stored and the sample drivers and customizable code resides. You will create your own configuration folders here (or the IDE will on your behalf, depending on your preferences). Like the folders off of the root, everything in the PUBLIC folder other than your own configuration folders should be considered hands off. If you need to modify something in these folders, make a copy of the source files and put them into your own configuration or platform—but don't modify these. Why? Because you will give yourself nightmares when dealing with add-on packs, QFEs, and Tools version upgrades—all of which can alter the contents of those folders as needed. (Been there, done that, worn out the stinky T-shirt!)

CESYSGEN Phase (CEBUILD.BAT, sysgen.bat)

This is the first phase of the build process. This step will process the headers and .lib files for the whole system. New with Talisker is the ability to optionally process the platform files as well. This is primarily useful for development systems, like a Windows CE–based PC hardware development platform (CEPC), where the actual hardware may support a whole lot more capability then the particular operating system configuration requires. If you take a look at the registry for the emulation under %_WINCEROOT%\platform\CEPC\files\platform.reg, you will see the following near the top of the file:

; @CESYSGEN IF FILESYS_FSREGHIVE
; HIVE BOOT SECTION
[HKEY_LOCAL_MACHINE\init\BootVars]
   "SYSTEMHIVE"="Documents and Settings\\system.hv"
   "PROFILEDIR"="Documents and Settings"
   "Start DevMgr"=dword:0
; END HIVE BOOT SECTION
; @CESYSGEN ENDIF FILESYS_FSREGHIVE

The CESYSGEN filtering looks for a commented line of the form:

@CESYSGEN IF <Environment Var Name>

and closed by a corresponding line:

@CESYSGEN ENDIF <Environment Var Name>

In the case above, if the environment variable FILESYS_FSREGHIVE is set, then the block of registry data is included in the filtered output; otherwise, it's removed.

The filtered data for a BSP is placed in the cesysgen folder of the BSP. Files filtered for the configuration, and all the system headers and files filtered, are placed in the platform configurations folder under WINCE400\cesysgen.

In the IDE, this phase has two names: generate system headers and re-generate system headers. They each do effectively the same thing. Re-generate headers will first "clean" the build output and then generate the headers, so that everything is re-generated from scratch. This will take a longer time to complete, but it is sometimes necessary when making wholesale changes in your configuration. Once you've settled on an operating system configuration, this phase is normally not repeated for every build. So either way it's not a major factor.

Figure 17. Filtered output

BSP Phase (Build.exe)

The BSP (and later stages) are run the most when developing a new system. This phase compiles and links all of your drivers and OAL code. How does the system know what to build? Glad you asked!

There's a special set of files used in this stage; these files are the guides to the build process, determining what needs to compile and link. The DIRS file defines where the build system should look to find things to build. The SOURCES file defines what is built and how it's built. Both of these are simple text files that are really just includes to a massive makefile system. So the syntax of both files is based on that of a makefile. The DIRS file is roughly equivalent to a workspace in the C and C++ development environments. The SOURCES file is roughly equivalent to a project. The DIRS file syntax is pretty simple, as seen in the version of it in the CEPC BSP:

DIRS= \
    gwe      \
    drivers  \
    eboot \
    sboot \
    kernel

As you can see, it's just a list of directories for the build system to scan. During the BSP phase, the DIRS file is read and directories listed in it are scanned for another DIRS file or a SOURCES file (you can't have both) to process.

The SOURCES file is a bit more complex, but basically it sets up linker and compiler settings and specifies the source code files to include in the build for the module. The complete syntax of a sources file is beyond the scope of this particular article. It is documented in the help files and there are numerous samples to learn from. (Perhaps we'll revisit that subject in another article. Send us some feedback, and let us know if you think it's important enough.) The output of the BSP phase is normally placed in a CPU-specific directory in the platform for EXEs and DLLs on an emulator build. That is, C:\WINCE400\PLATFORM\EMULATOR\lib\x86\[retail | debug] for libraries, and C:\WINCE400\PLATFORM\EMULATOR\target\x86\[retail | debug] for EXE and DLL modules. This is done to allow a SOURCES file to generate a .lib file that is used by multiple other pieces in the OAL and not directly used anywhere else.

BUILDREL Phase (BuildRel.BAT)

This phase is focused on collecting files from various parts of the build and copying them all to a single flat release directory (%_FLATRELEASEDIR%). The files and target folders contents from the BSP are copied in to get the modules built in the BSP Phase, along with BSP-specific configuration settings from the BSP's Files directory. When using the IDE, your Platform Builder projects are built after all the files are copied over to the _FLATRELEASEDIR.

MAKEIMG Phase (makeimg.exe)

This is the final stage in the build process. It combines everything into a binary image file(s) for placement on your target hardware. It is implemented in three primary internal stages.

The first stage merges all of the various configuration files (BIB, DAT, REG, DB—we'll detail these files in just a bit) into one master file for each type. The following table shows the files and their corresponding master-merged file.

Original files Merged file Description
Common.bib, Config.bib, Project.bib, Platform.bib Ce.bib Identifies all the Windows CE files to be combined into the operating system image.
Common.reg, Project.reg, Platform.reg Reginit.ini Provides a collection of registry entries for the operating system image.
Common.dat, Project.dat, Platform.dat Initobj.dat Provides a description of the directory and file locations for the operating system image.
Common.db, Project.db, Platform.db Initdb.ini Defines the creation of any databases in the Windows CE object store.

The registry file, reginit.ini, is further compressed into default.fdf. You can also merge in your own settings for drivers or other applications you add to the system using PBMERGE.exe. (CEC files in the IDE allow adding BIB entries automatically.)

In the second stage following the merge, makeimg will process all of the EXE and DLL modules specified in LOC files to replace the resources for the current language specified for the build.

After the resources are updated, the makeimg will run ROMIMAGE as the third stage. This will link and locate all execute-in-place code files in the image, and create a ROM file system image for all the other files. This file system is merged with the RAM and other file systems within the Windows CE single-rooted file system. All files in ROM are located in the \Windows Folder.

RomImage will generate the final image as NK.BIN, and optionally as an SRE or as absolute binary image(s) suitable for burning directly into Flash. SRE is an ASCII Hex text-based file format used by a number of embedded systems tools and ROM/FLASH programmers. The BIN file is a Microsoft-specific format similar to an SRE or Intel HEX format. However, instead of using ASCII hex characters, the BIN file uses actual binary data, thus decreasing the size of the image file by about half.

Build Configuration Files

REG Files

REG files for the Windows CE .NET 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 Microsoft developer 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 .NET is Cool!","KillerApp iz da BOSS!"
   "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 .NET is Cool!\0KillerApp Iz da BOSS!\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 ActiveSynch.

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:

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

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

Putting It All Together Again

Now that you've examined the parts of the build, let's walk through what happens in a quick refresher to pull it all together.

  1. The sysgen phase filters the headers and libraries for the operating system and optionally the BSP.
  2. The BSP phase builds the OAL and links it to the kernel, and builds drivers and links native drivers to GWES.
  3. The Buildrel stage copies the data files and executable files into the _FLATRELEASEDIR.
  4. Makeimage merges the BIB, DAT, DB, and REG files, compresses the registry to default.fdf, links and locates all the modules in the modules section of the merged CE.bib, and generates the image file.

This is further extended in the IDE with CEC files that allow you to inject functionality before and after virtually all of the phases. We'll leave that for a future article on Board Support Packages.

Wrapping Up…

In this article we've walked through a typical build and download scenario, and have taken our first look at how the build system works. Over the coming months, we will dig deeper into each of the areas we have touched upon, including the tools (Platform Builder and Remote Tools) and technologies used to customize the Windows CE operating system.

 

Get Embedded

Mike Hall is a Product Manager in the Microsoft Embedded and Appliance Platform Group (EAPG). Mike has been working with Windows CE since 1996—in developer support, Embedded System Engineering, and the Embedded product group. When not at the office, Mike can be found with his family, working on Skunk projects, or riding a Honda ST1100.

Steve Maillet is the Founder and Senior Consultant for Entelechy Consulting. Steve has provided training and has developed Windows CE solutions for clients since 1997, when CE was first introduced. Steve is a frequent contributor to the Microsoft Windows CE development newsgroups. When he's not at his computer burning up the keys, Steve can be found jumping out of airplanes at the nearest drop zone.