Microsoft Windows Embedded CE 6.0 Exam Preparation Kit

The Windows Embedded CE build process is the final step in the run-time image development cycle. Based on the settings defined in the OS design, Platform Builder compiles all components, including subprojects and the BSP, and then creates a runtime image that you can download to the target device. The build process entails several build phases, automated by means of batch files. You must understand these phases and the build tools if you want to configure build options correctly, create runtime images efficiently, and solve build-related issues.

Build Process Overview

The Windows Embedded CE build process includes four main phases, as illustrated in Figure 2-1. They follow each other sequentially, but you can also carry them out independently if you know the purpose and tools used for each phase. By selectively running the build tools, you can perform individual build steps in a targeted way, which helps to save build time and ultimately increases your efficiency.

Figure 2-1 Build phases and build tools

The build process includes the following key phases:

■ Compile phase Compiler and linker use source code and resource files to generate executable (.exe) files, static (.lib) libraries, dynamic-link library (.dll) files, and binary resource (.res) files according to the selected locales. For example, the build system compiles the source code in the Private and Public folders into .lib files during this phase. This process can take several hours to complete, but fortunately it is seldom required to rebuild these components because binaries are already provided by Microsoft. In any case, you should not modify the source code in the Private and Public folders.

■ Sysgen phase The build system sets or clears SYSGEN variables based on the catalog items and dependency trees included in the OS design, filters the header files and creates import libraries for the Software Development Kits (SDKs) defined in the OS design, creates a set of run-time image configuration files for the OS design, and builds the BSP based on the source files in the Platform directory.

■ Build phase The build system processes the source files of your Board Support Package and applications using the files generated during the Sysgen phase. At this time, hardware-linked drivers and the OEM adaptation layer (OAL) are built. Although the processes during the build phase are carried out automatically during the Sysgen phase, it is important to understand that if you modify only the BSP and subprojects, then you can rebuild the BSP and subprojects without running the Sysgen tool again.

■ Release Copy phase The build system copies all files required to create the runtime image to the OS design's release directory. This includes the .lib, .dll, and .exe files created during the Compile and Sysgen phases, as well as binary image builder (.bib) and registry (.reg) files. The build system might skip this phase if headers and libraries are up-to-date.

■ Make Run-time Image phase The build system copies project-specific files (Project.bib, Project.dat, Project.db, and Project.reg) to the release directory and assembles all files in the release directory into a run-time image. Directives based on environment variables specified in .reg and .bib files control which catalog items the build system includes in the final run-time image. The run-time image is typically a file named Nk.bin, which you can download and run on the target device.

Building Run-Time Images in Visual Studio

During the installation of Windows Embedded CE 6.0 R2 on your development workstation, Platform Builder integrates with Visual Studio 2005 and extends the Build menu so that you can control the build process directly in the Visual Studio IDE. Figure 2-2 shows the Platform Builder commands that are available on the Build menu when you select the OS design node in Solution Explorer.

Figure 2-2 Windows Embedded CE build commands in Visual Studio 2005

You can use the Platform Builder commands on the Build menu to perform selective build steps or a combined series of steps that span multiple build phases. For example, you can use the Copy Files To Release Directory command to ensure that the build system copies updated .bib and .reg files to the release directory even if header files and libraries have not changed. Otherwise, the build system skips the Release Copy phase and .bib file or .reg file changes are not applied to the run-time image.

Table 2-1 summarizes the purpose of the Windows Embedded CE build commands.

Table 2-1 Windows Embedded CE build and rebuild commands

The Advanced Build Commands submenu provides access to several Platform Builder-specific build commands that you might find useful on a regular basis. For example, you need to run the Sysgen or Clean Sysgen command when you add or remove catalog components to or from the OS design to create the binary versions for the run-time image. Exceptions to this rule are components that do not modify SYSGEN variables, such as components in the ThirdParty folder. It is not necessary to run Sysgen or Clean Sysgen when you select or deselect these items. Following the Sysgen phase, Platform Builder continues the build process similar to running the Build Current BSP And Subprojects command.

You can select the Build Current BSP And Subprojects or the Rebuild Current BSP And Subprojects commands in Visual Studio if you want to compile and link the source code in the Platform directory and any subprojects in the OS design and put the code into the target directory under Platform\<BSP Name>\Target and Platform\<BSP Name>\Lib. This is necessary, for instance, if you modify the source code in the Platform directory. Depending on the Copy Files To Release Directory After Build and Make Run-Time Image After Building options, Platform Builder copies the files to the release directory and creates the run-time image. You can also perform these steps individually either through the menu or by running the Buildrel.exe and Makeimg.exe tools at the command prompt.

Building Run-Time Images from the Command Line

The Platform Builder for CE6 R2 plug-in for Visual Studio 2005 provides convenient access to batch files and build tools, but you can also run these batch files and build tools directly at the command prompt. Each build command in Visual Studio with Platform Builder corresponds to a specific build command, as listed in Table 2-2. Remember, however, to use the Open Build Window command in Visual Studio to open a Command Prompt window for this purpose. The standard command prompt does not initialize the development environment. The build process will fail without the presence of the required environment variables.

Table 2-2 Build commands and command line equivalents

* Not recommended

Windows Embedded CE Run-Time Image Content

MODULES

; Name         Path                Memory Type

; --------------    ----------------------------    -----------

; @CESYSGEN IF CE_MODULES_DISPLAY

IF BSP_NODISPLAY !

DeviceEmulator_lcd.dll $(_FLATRELEASEDIR)\DeviceEmulator_lcd.dll NK SHK

IF BSP_NOBACKLIGHT !

backlight.dll     $(_FLATRELEASEDIR)\backlight.dll     NK SHK

ENDIF BSP_NOBACKLIGHT !

ENDIF BSP_NODISPLAY !

; @CESYSGEN ENDIF CE_MODULES_DISPLAY

FILES

; Name      Path             Memory Type

; -------------- ---------------------------- -----------

; @CESYSGEN IF CE_MODULES_PPP

dmacnect.lnk   $(_FLATRELEASEDIR)\dmacnect.lnk  NK SH

; @CESYSGEN ENDIF CE_MODULES_PPP

; Our variables

#define BUILTIN_ROOT HKEY_LOCAL_MACHINE\Drivers\BuiltIn

;#define PCI_BUS_ROOT $(BUILTIN_ROOT)\PCI

#define DRIVERS_DIR $(_PUBLICROOT)\common\oak\drivers

; @CESYSGEN IF CE_MODULES_RAMFMD

; @CESYSGEN IF FILESYS_FSREGHIVE

; HIVE BOOT SECTION

[HKEY_LOCAL_MACHINE\init\BootVars]

"Flags"=dword:1 ; see comment in common.reg

; END HIVE BOOT SECTION

; @CESYSGEN ENDIF FILESYS_FSREGHIVE

; @CESYSGEN IF CE_MODULES_PCCARD

; @XIPREGION IF DEFAULT_DEVICEEMULATOR_REG

IF BSP_NOPCCARD !

#include "$(_TARGETPLATROOT)\src\drivers\pccard\pcc_smdk2410.reg"

#include "$(DRIVERS_DIR)\pccard\mdd\pcc_serv.reg"

[HKEY_LOCAL_MACHINE\Dri vers\PCCARD\PCMCIA\TEMPLATE\PCMCIA]

"Dll"="pcmcia.dll"

"NoConfig"=dword:1

"NoISR"=dword:1 ; Do not load any ISR.

"IClass"=multi_sz:"{6BEAB08A-8914-42fd-B33F-61968B9AAB32}=

PCMCIA Card Services"

ENDIF ; BSP_NOPCCARD !

; @XIPREGION ENDIF DEFAULT_DEVICEEMULATOR_REG

; @CESYSGEN ENDIF CE_MODULES_PCCARD

Root:-Directory("Program Files")

Root:-Directory("My Documents")

Directory("\Program Files"):-Directory("My Projects")

Directory("\My Documents"):-File("MyFile.doc", "\Windows\Myfile.doc")

Lesson Summary

A thorough understanding of the build system can help to decrease development time and therefore project costs. You must know the steps performed during each phase of the build process if you want to test source code changes quickly and without unnecessary compilation cycles. You must also know the purpose and location of the run-time image configuration files, such as .reg, .bib, .db, and .dat files, to create and maintain OS designs efficiently.

The Windows Embedded CE build system combines the various .reg, .bib, .db, and .dat files during the Make Run-time Image phase into consolidated files that the build system then uses to configure the final run-time image. It is a good idea to check these files if you want to verify that a specific setting or file made it into the final image without having to load the run-time image on the target device. You can find the various run-time image configuration files in the release directory of the OS design. If you discover that expected entries are missing, check the conditional statements and the environment variables and SYSGEN variables defined in your catalog items.

The build system creates the following run-time image configuration files during the Make Run-time Image phase:

■ Reginit.ini Combines the Platform.reg, Project.reg, Common.reg, IE.reg, Wceapps.reg, and Wceshell.reg files.

■ Ce.bib Combines the Config.bib, Platform.bib, Project.bib, and Subproject bib files.

■ Initdb.ini Combines the Common.db, Platform.db, and Project.db files.

■ Initobj.dat Combines the Common.dat, Platform.dat, and Project.dat files.

In addition to run-time image configuration files, Windows Embedded CE also uses build configuration files to compile and link source code into functional binary components. Specifically, the build system relies on three types of source code configuration files: Dirs, Sources, and Makefile. These files provide the Build tool (Build.exe) and the compiler and linker (Nmake.exe) with information about the source-code directories to traverse, the source code files to compile, and what type of binary components to build. As a CE developer, you frequently must edit these files, such as when cloning public catalog items, by following the procedures discussed in Chapter 1.

Dirs Files

Dirs files identify directories that contain source-code files to be included in the build process. When Build.exe finds a Dirs file in the folder in which it is run, it traverses the subdirectories referenced in the Dirs file to build the source code in these subdirectories. Among other things, this mechanism enables you to update parts of a run-time image selectively. If you make changes to the source code in Subprojectl, you can rebuild this subproject selectively by running Build.exe in the Subprojectl directory. You can also exclude directories in the source code tree from the build process by removing the corresponding directory references from the Dirs file, or by using conditional statements.

Dirs files are text files with a straightforward content structure. You can use the DIRS, DIRS_CE, or OPTIONAL_DIRS keyword, and then specify the list of subdirectories on a single line, or on multiple lines if you terminate each line with a backslash to continue on the next line. Directories referenced by using the DIRS keyword are always included in the build process. If you use the DIRS_CE keyword instead, Build.exe only builds the source code if the source code is written specifically for a Windows Embedded CE run-time image. The OPTIONAL_DIRS keyword designates optional directories. Keep in mind, however, that Dirs files can contain only one DIRS directive. Build.exe processes the directories in the order they are listed, so be sure to list prerequisites first. It is also possible to use the wildcard "*" to include all directories.

The following listing, taken from default Windows Embedded CE components, illustrates how to include source code directories in the build process by using Dirs files.

# C:\WINCE600\PLATFORM\DEVICEEMULATOR\SRC\Dirs 

# --------------------------------------------------- 

DIRS=common \ 

 drivers \ 

 apps   \ 

 kitl   \ 

 oal   \ 

 bootloader 

# C:\WINCE600\PLATFORM\H4SAMPLE\SRC\DRIVERS\Dirs 

# --------------------------------------------------- 

DIRS= \ 

# @CESYSGEN IF CE_MODULES_DEVICE 

 buses \ 

 dma \ 

 triton \ 

# @CESYSGEN IF CE_MODULES_KEYBD 

 keypad \ 

# @CESYSGEN ENDIF CE_MODULES_KEYBD 

# @CESYSGEN IF CE_MODULES_WAVEAPI 

 wavedev \ 

# @CESYSGEN ENDIF CE_MODULES_WAVEAPI 

# @CESYSGEN IF CE_MODULES_POINTER 

 touch \ 

 tpagent \ 

# @CESYSGEN ENDIF CE_MODULES_POINTER 

# @CESYSGEN IF CE_MODULES_FSDMGR 

 nandflsh \ 

# @CESYSGEN ENDIF CE_MODULES_FSDMGR 

# @CESYSGEN IF CE_MODULES_SDBUS 

 sdhc \ 

# @CESYSGEN ENDIF CE_MODULES_SDBUS 

# @CESYSGEN IF CE_MODULES_DISPLAY 

 backlight \ 

# @CESYSGEN ENDIF CE_MODULES_DISPLAY 

# @CESYSGEN IF CE_MODULES_USBFN 

 usbd \ 

# @CESYSGEN ENDIF CE_MODULES_USBFN 

# @CESYSGEN ENDIF CE_MODULES_DEVICE 

# @CESYSGEN IF CE_MODULES_DISPLAY 

 display \ 

# @CESYSGEN ENDIF CE_MODULES_DISPLAY 

Sources Files

If you check the folders and files of a standard OS design, such as C:\Wince6OO\OSDesigns\OSDesignl, you will find that the project includes no Dirs files by default. If you include subprojects for custom components and applications, you will find a Sources file in each subproject's root folder instead. The Sources file provides more detailed information about the source-code files, including build directives, which a Dirs file cannot provide. However, a source-code directory can only contain one Dirs file or one Sources file, not both. That means that a directory with a Sources file cannot contain subdirectories with more code. During the build process, Nmake.exe uses the Sources files to determine what file type to build (.lib, .dll, or .exe), and how to build it. Similar to Dirs files, Sources files expect you to specify declarations in a single line, unless you terminate the line with a backslash to continue the declaration on the next line.

The following listing shows the content of a Sources file in the Device Emulator BSP. By default, you can find this file in the C:\Wince600\Platform\DeviceEmulator \Src\Drivers\Pccard folder.

WINCEOEM=1

TARGETNAME=pcc_smdk2410

TARGETTYPE=DYNLINK

RELEASETYPE=PLATFORM

TARGETLIBS=$(_COMMONSDKROOT)\lib\$(_CPUINDPATH)\coredll.lib \

      $(_SYSGENOAKROOT)\lib\$(_CPUINDPATH)\ceddk.lib

SOURCELIBS=$(_SYSGENOAKROOT)\lib\$(_CPUINDPATH)\pcc_com.lib

DEFFILE=pcc_smdk2410.def

DLLENTRY=_DllEntryCRTStartup

INCLUDES=$(_PUBLICROOT)\common\oak\drivers\pccard\common;$(INCLUDES)

SOURCES= \

Init.cpp \

PDSocket.cpp \

PcmSock.cpp \

PcmWin.cpp

#xref VIGUID {549CAC8D_8AF0_4789_9ACF_2BB92 599470D}

#xref VSGUID {0601CE65_BF4D_453A_966B_E20250AD2E8E}

You can define the following directives in a Sources file:

■ TARGETNAME This is the name of the target file, without file name extension.

■ TARGETTYPE Defines the type of file to be built, as follows:

■ DYNLINK A dynamic-link library (.dll).

■ LIBRARY A static-link library (.lib).

■ PROGRAM An executable file (.exe).

■ NOTARGET Build no file.

■ RELEASETYPE Specifies the directory where Nmake.exe places the target file, as follows:

■ PLATFORM PLATFORM\<BSP Name>\<Target>.

■ OAK, SDK, DDK %_PROJECTROOT%\Oak\<Target>.

■ LOCAL The current directory.

■ CUSTOM A directory specified in TARGETPATH.

■ MANAGED %_PROJECTROOT%\Oak\<Target>\Managed.

■ TARGETPATH Defines the path for RELEASETYPE=CUSTOM.

■ SOURCELIBS Specifies libraries to be linked with the target file specified in TARGETNAME to create the final binary output. This option is typically used for creating a .lib file but not .dll or .exe files.

■ TARGETLIBS Specifies additional libraries and object files to link to the final binary output, typically used for creating .dll or .exe files but not for .lib files.

■ INCLUDES Lists additional directories to search for include files.

■ SOURCES Defines the source files to be used for this particular component.

■ ADEFINES Specifies parameters for the assembler.

■ CDEFINES Specifies parameters for the compiler, which can be used as additional DEFINE statements for use in IFDEF statements.

■ LDEFINES Sets linker definitions.

■ RDEFINES Specifies DEFINE statements for the resource compiler.

■ DLLENTRY Defines the entry point for a DLL.

■ DEFFILE Defines the .def file which contains a DLL's exported symbols.

■ EXEENTRY Sets the entry point of an executable file.

■ SKIPBUILD Marks the build of the target as successful without an actual build of the target.

■ WINCETARGETFILE0 Specifies nonstandard files that should be built before building the current directory.

■ WINCETARGETFILES This macro definition specifies nonstandard target files that Build.exe should build after Build.exe links all other targets in the current directory.

■ WINCE_OVERRIDE_CFLAGS Defines compiler flags to override default settings.

■ WINCECPU Specifies that the code requires a certain CPU type and should only be built for that particular CPU.

Makefile Files

If you look closer at the contents of a subproject folder, you can also find a file named Makefile to provide default preprocessing directives, commands, macros, and other expressions to Nmake.exe. However, in Windows Embedded CE, this Makefile includes only a single line that references %_MAKEENVROOT%\Makefile.def. By default, the environment variable %_MAKEENVROOT% points to the C:\Wince6OO\Public\Common\Oak\Misc folder and the Makefile.def file in this location is the standard Makefile for all CE components, so you should not modify this file. Among other things, the Makefile.def file contains include statements to pull in Sources file, such as !INCLUDE $(MAKEDIR)\sources, which specify the Sources file from the subproject folder. You should edit the Sources file in the subproject folder to adjust the way Nmake.exe builds the target file.

Lesson Summary

The Windows Embedded CE 6.0 R2 development environment relies on Makefile, Sources, and Dirs files to control how Build.exe and Nmake.exe compile and link source code into functional binary components for the run-time image. You can use Dirs files to define the source code directories included in the build process or Sources files to specify compile and build directives in greater detail. The Makefile, on the other hand, requires no customization. It merely references the default Makefile.def file with general preprocessing directives, commands, macros, and other processing instructions for the build system. You must thoroughly understand the purpose of files and how they control the build process if you want to clone public catalog items or create new components efficiently.

You are certain to encounter build errors during the software-development cycle. In fact, it is not uncommon to use compile errors as a syntax check for source code, although IntelliSense® and other coding aids available in Visual Studio 2005 help to reduce the amount of typos and other syntax errors. Syntax errors are relatively uncomplicated to fix because you can double-click the corresponding error message in the Output window and jump right to the critical line in the source code file. However, compiler errors are only one type of build errors that can occur. Other common build errors are math errors, expression evaluation errors, linker errors, and errors related to run-time image configuration files. In addition to error messages, the build system also generates status messages and warnings to help you analyze and diagnose build issues. The amount of information generated during the build process can be overwhelming. You need to know the different types and general format of build messages if you want to identify, locate, and solve build errors efficiently.

Understanding Build Reports

When you perform a build either in the Visual Studio IDE or the command prompt, the build process outputs a significant amount of build information. The build system tracks this information in a Build.log file. Details about compilation or linker warnings and errors also can be found in the Build.wrn and Build.err files. If you started a complete build or a Sysgen operation for an OS design by using one of the corresponding commands on the Build menu in Visual Studio, the build system writes these files in the %_WINCEROOT% folder (by default, C:\Wince600). On the other hand, if you perform a build for only a particular component, such as by right- clicking a subproject folder in Solution Explorer and clicking the Build command from the context menu, the build system writes these files in that specific directory. In either case, the Build.wrn and Build.err files only exist if you encounter warnings and errors during the build process. However, you do not need to open and parse through these files in Notepad or another plain-text editor. Visual Studio 2005 with Platform Builder for CE 6.0 R2 displays this information during the build process in the Output window. You can also examine status messages, warnings, and errors in the Error List window that you can display by clicking Error List, which is available under Other Windows on the View menu.

Figure 2-6 shows the Output window and the Error List window in undocked view. The Output window displays the Build.log content if you select Build from the Show Output From list box. The Error List window displays the contents Build.wrn and Build.err files.

Figure 2-6 Output window and Error List window with build information in Visual Studio

Specifically, you can find the following information in the build log files:

■ Build.log Contains information about the individual commands issued within each phase during the build process. This information is useful for analyzing both the build process in general, and build errors in particular.

■ Build.wrn Contains information about warnings generated during the build process. If possible, try to eliminate or at least identify the reasons for the warnings. The information in Build.wrn is also included in Build.log.

■ Build.err Contains specific information about build errors encountered during the build process. This information is also available with additional details in Build.log. This file is created only when an error occurs.

Troubleshooting Build Issues

Lesson Summary

Platform Builder for Windows Embedded CE 6.0 R2 integrates with the build-logging system of Visual Studio 2005 to provide you with convenient access to status information, warnings, and error messages generated during the build process and tracked in Build.log, Build.wrn, and Build.err files. Depending on how you start the build process in Visual Studio, these files reside either in the %_WINCEROOT% folder or in a subproject directory, yet the actual location of the files is not important because you can analyze the content from these files directly in the Output window and the Error List window in Visual Studio. It is not necessary to open these files in Notepad or another text editor.

By analyzing build log files, you can gain a better understanding of the build process in general and build issues in particular. Typical build issues you might encounter occasionally are compiler errors, linker errors, Sysgen errors, build errors, and other errors generated during the Release Copy and Make Run-time Image phases. If a build error is related directly to a line in a source code file, you can double-click the message entry in the Error List window, and Visual Studio automatically opens the source-code file and jumps to the critical line. Other issues, such as buildrel errors due to inadequate hard drive space, require you to perform troubleshooting steps outside of the Visual Studio IDE.

Having solved all build issues and successfully generated a run-time image, you are ready to deploy Windows Embedded CE on the target device. There are several ways to accomplish this task. The method you choose depends on the startup process you use to load Windows Embedded CE on the target device. There are several ways you can start a Windows Embedded CE 6.0 run-time image. You can start an image directly from ROM, in which case you must deploy the run-time image on the target device by using a ROM tool. You can also use a boot loader, and then either download the run-time image every time the device starts or store the image in persistent memory for reuse. Windows Embedded CE 6.0 R2 comes with generic boot-loader code that you can customize according to your specific needs. It is also straightforward to implement a third-party boot loader. Essentially, Windows Embedded CE can accommodate almost any start environment, and makes it easy to download new run-time images quickly and conveniently during the development cycle and for release to the end user.

Choosing a Deployment Method

Attaching to a Device

Having configured the device connection, you are ready to transfer the run-time image to the target device or device emulator by using the Core Connectivity infrastructure. This is accomplished in Visual Studio 2005 by using the Attach Device command that is available on the Target menu. Even if you do not plan to use KITL or the Core Connectivity infrastructure for debugging, you must attach to the device so that Platform Builder can download the run-time image.

Following the image download, the start process commences, KITL becomes active if enabled on the target device, and you can use the Kernel Debugger to follow the start process, and debug operating system components and application processes. By using KITL, you can also exploit remote tools available in Visual Studio with Platform Builder on the Target menu, such as File Viewer to interact with the device's file system, Registry Editor to access the device's registry settings, Performance Monitor to analyze resource utilization and response times, and Kernel Tracker and other remote tools to view detailed information on the running system. You can find more information about system debugging in Chapter 4, "Debugging and Testing the System."

Lesson Summary

Windows Embedded CE supports run-time image deployment over a variety of device connections to accommodate hardware platforms with varying requirements and capabilities, including Ethernet connections, serial connections, DMA, and USB connections. For example, DMA is the right choice if you want to deploy CE 6.0 R2 on a Device Emulator. You only need to configure the communication parameters and you are ready to deploy Windows Embedded CE by clicking the Attach Device command on the Target menu in Visual Studio 2005 with Platform Builder.

In this lab, you build and deploy an OS design based on the Device Emulator BSP, analyze the build information in the Visual Studio Output window to identify the start of the various build phases, and then configure a connection to a target device in order to download the run-time image. To demonstrate how to customize a target device, you modify the Device Emulator configuration to support a larger screen resolution and to enable network communication. In a final step, you download the run-time image and attach to the target device with the Kernel Debugger, so you can examine the Windows Embedded CE start process in detail. To create the initial OS design in Visual Studio, follow the procedures outlined in Lab 1, "Creating, Configuring, and Building an OS Design."

Build a Run-Time Image for an OS Design

1. After completing Lab 1, select Sysgen under Advanced Build Commands on the Build menu in Visual Studio, as illustrated in Figure 2-8. Alternatively, you can select Build Solution under the Build menu, which will perform a build starting with the Sysgen step.

2. Follow the build process in the Output window. Examine the build information to identify the SYSGEN, BUILD, BUILDREL, and MAKEIMG steps. You can press Ctrl+F to display the Find And Replace dialog box, and then search for the following text to identify the start of these phases:

a. Starting Sysgen Phase For Project The SYSGEN steps start.

b. Build Started With Parameters The BUILD steps start.

c. C:\WINCE600\Build.log The BUILDREL steps start.

d. BLDDEMO: Calling Makeimg — Please Wait The MAKEIMG steps starts.

3. Open the C:\Wince600 folder in Windows Explorer. Verify that Build.* files exist.

4. Open the Build.* files in a text editor, such as Notepad, and examine the content.

Figure 2-8 Building an OS design

Configure Connectivity Options

1. In Visual Studio, open the Target menu and select Connectivity Options to display the Target Device Connectivity Options dialog box.

2. Verify that CE Device is selected in the Target Device list box.

3. Select Device Emulator (DMA) from the Download list box.

4. Select Device Emulator (DMA) from the Transport list box.

5. Select KdStub from the Debugger list box, as illustrated in Figure 2-9.

Figure 2-9 Setting Target Device Connectivity Options

Change the Emulator Configuration

1. Next to the Download list box, click the Settings button.

2. In the Emulator Properties dialog box, switch to the Display tab.

3. Change the Screen Width to 640 pixels and the Screen Height to 480 pixels.

4. Switch to the Network tab.

5. Select the Enable NE2000 PCMCIA Network Adapter And Bind To check box, then select the Connected Network Card option from the list box, as illustrated in Figure 2-10, and then click OK.

6. Click Apply to save the new device configuration.

7. Click Close to close the Target Device Connectivity Options dialog box.

Figure 2-10 Device Emulator network options

Test a Run-Time Image on the Device Emulator

1. In Visual Studio, open the Target menu, and then click Attach Device.

2. Verify that Visual Studio downloads the run-time image to the target device. The download can take several minutes to complete.

3. Follow the debug messages during the start process in the Visual Studio Output window.

4. Wait until Windows Embedded CE has completed the start process, and then interact with the Device Emulator and test the features of your OS design, as illustrated in Figure 2-11.

Figure 2-11 Windows Embedded CE device emulator

The Windows Embedded CE build process includes several phases and relies on a variety of build and run-time image configuration files to compile the source code and create the run-time image. It includes a compile phase to generate .exe files, static libraries, DLLs, and binary resource (.res) files for the BSP and subprojects; a Sysgen phase to filter and copy source code based on SYSGEN variables from the Public folder for catalog items selected in the OS design, and create a set of run-time image configuration files; a Release Copy phase to copy the files from the BSP and subprojects required to build the run-time image into the release directory; and finally a Make Run-time Image phase to create the run-time image from the content in the release directory according to the setting specified in .bib, .reg, .db, and .dat files.

You can examine the build process if you analyze the information that Platform Builder generates and tracks in Build.log, Build.wrn, and Build.err files. The Build.log file contains detailed information about every build command issued in each build phase. Build.wrn and Build.err contain the same information, but filtered for warnings and errors encountered during the build process. You do not need to open these text files directly in Notepad. It is more convenient to work with build status information and error messages in Visual Studio. The Output window and the Error List window provide convenient access.

Build errors can occur for a variety of reasons. The most common causes are compiler and linker errors. For example, running build commands in an incorrectly initialized build environment will lead to linker errors when environment variables that identify library directories in the Sources file point to invalid locations. Other important build configuration files, such as Dirs files and Makefile.def, can also rely on SYSGEN variables and environment variables in conditional statements and in directory paths.

Having successfully generated a run-time image, you can deploy Windows Embedded CE on a target device. This requires you to configure a device connection based on the Core Connectivity infrastructure. The final deployment step is simply to click the Attach Device command that you can find on the Target menu in Visual Studio with Platform Builder for Windows Embedded CE 6.0 R2.

It is important that you are familiar with the following configuration files, which control the Windows Embedded CE build process:

■ Binary image builder (.bib) files Configure the memory layout and determine the files included in the run-time image.

■ Registry (.reg) files Initialize the system registry on the target device.

■ Database (.db) files Set up the default object store.

■ File system (.dat) files Initialize the RAM file system layout at start time.

■ Dirs files Determine which directories to include in the build process.

■ Sources files Define preprocessing directives, commands, macros, and other processing instructions for the compiler and linker. Take the place of Makefile files in the Visual Studio with Platform Builder IDE.

■ Makefile files Reference the default Makefile.def file and should not be edited.

Key Terms

Do you know what these key terms mean? You can check your answers by looking up the terms in the glossary at the end of the book.

■ Sysgen

■ Buildrel

■ Flat release directory

■ Connectivity options

■ KITL

Suggested Practice