一、wince5.0开发概述

1.   OEM Adaptation Layer

An OEM adaptation layer (OAL) is a layer of code that logically resides between the Windows CE kernel and the hardware of your target device. Physically, the OAL is linked with the kernel libraries to create the kernel executable file.

The OAL facilitates communication between your operating system (OS) and your target device and includes code to handle interrupts, timers, power management, bus abstraction, generic I/O control codes (IOCTLs), and so on.

Creating the OAL is one of the more complex tasks in the process of getting a Windows CE–based OS to run on a new hardware platform. In general, the easiest way to create an OAL is to copy the OAL implementation from a working OS design, and then modify it to suit the specific requirements of your hardware platform.

If you must create an OAL from the beginning, the task can be greatly simplified by approaching the development process in stages. Each stage adds a little more functionality than the previous one and provides a convenient separation point where new functionality can be fixed and validated before proceeding to the next step.

2.  OS Design Configuration Files

The files that Platform Builder uses during the build process can be separated into two general categories of configuration files, source code configuration files and image configuration files:

Source code configuration files are used by the Build tool to build modules and features and to build the source code for your run-time image.
Run-time image configuration files are used by a number of tools that are called by the Make Binary Image Tool to create the run-time image.

3.  Boot Loaders

The boot loader is a utility that is an integral part of the OEM device development process. In some cases, it is also included in the final OEM product. The general purpose of the boot loader is to place the run-time image into memory, and then jump to the OS startup routine. The boot loader can obtain the run-time image in a number of different ways, including loading it over a cabled connection, such as Ethernet, a universal serial bus (USB), or serial connection. The boot loader also loads the OS from a local storage device, such as Compact Flash, or a hard disk. The boot loader might store the run-time image in RAM or in nonvolatile storage, such as flash memory, electrically erasable programmable read only memory (EEPROM), or some other storage device for later use.

Using the boot loader during the board support package (BSP) development process saves time. You can quickly download a new run-time image to a target device using a boot loader rather than manually transferring the run-time image to a target device using a flash memory programmer or IEEE 1149.1-compliant test access port and boundary-scanning technology.

In many final OEM products, the boot loader is removed from the product and the system reset process bootstraps the run-time image, which is stored on the device. However, hardware platforms that do not efficiently support this ability, such as x86 platforms, or hardware platforms that need to perform pre-boot tasks, such as run-time image updates, might include the boot loader in the final product.

Although each boot loader differs in the tasks it carries out and the way it performs them, the most common boot loader downloads the run-time image over Ethernet into RAM on a target device.

4. Developing a Device Driver

A device driver is software that abstracts the functionality of a physical or virtual device. A device driver manages the operation of these devices. Examples of physical devices are network adapters, timers, and universal asynchronous receiver-transmitters (UARTs). An example of a virtual device is a file system. Implementing a device driver allows the functionality of your device to be exposed to applications and other parts of the operating system (OS). While developing a device driver, take advantage of the services provided by the OS. Although Windows CE device drivers are trusted modules, they do not have to run in kernel mode.

Many Windows CE device drivers implement the stream interface. The core stream interface entry points are XXX_Open (Device Manager), XXX_Close (Device Manager), XXX_Read (Device Manager), and XXX_Write (Device Manager). For more information, see Stream Interface Drivers.

Network adapters, display adapters, mouse devices, keyboards, and other special-purpose devices do not use the stream interface. These devices use an interface that suits the device's functionality.

Regardless of the interface that your device driver exposes, you might have to implement an interrupt service routine (ISR). For more information about interrupts and ISRs, see Interrupts.

Different processes load different drivers. The following table shows the processes that load drivers and what drivers each process loads.

Process	Drivers
File System (FileSys.exe)	FileSys.exe loads file system drivers. For more information, see tabindex="tabindex" keywords="wce50conFileSystems3">File Systems.
Device Manager (Device.exe)	Device.exe loads audio drivers, battery drivers, keyboard drivers, mouse drivers, NDIS drivers, notification LED drivers, serial drivers, PC Card drivers, USB drivers, and any other driver that exposes the stream interface. Device.exe loads most of its drivers with ActivateDeviceEx, and these drivers expose a stream interface. For more information, see tabindex="tabindex" keywords="wce50conDeviceManager">Device Manager.
Graphics, Windowing, and Events Subsystem (GWES.exe)	GWES.exe loads a device driver if GWES is the only client of a driver. Device drivers loaded by GWES present a standard set of functionality for all similar devices. Drivers that GWES loads might expose the stream interface or they might expose other interfaces. Having alternatives make accessing the drivers much faster. GWES loads display drivers, printer drivers, and touch screen drivers. For more information, see tabindex="tabindex" keywords="wce50conShellandUserInterface146">Shell and User Interface Overview.

5.Terminology(术语)

Technorati 标签: Terminology(术语)

Some of the terminology in Microsoft® Windows® CE 5.0 differs from terminology in previous versions of Windows CE.

The following list provides definitions for terms that are new and widely used in Windows CE 5.0:

Catalog item

Any item that you can select from the Catalog.

design template

A pre-defined selection of operating system (OS) components that Microsoft provides for a category of target devices. A design template is a starting point. When saved or modified, the design template becomes an OS design.

OS design

A selection of Catalog items that defines the characteristics of an OS. You can begin an OS design with or without a design template. An OS design corresponds to a set of Sysgen variables.

run-time image

Software to deploy on a target device, or the same software running on a target device. A run-time image contains the OS and associated software.

The following list provides definitions for other terms that are widely used in Windows CE 5.0:

board support package (BSP)

Software that is specific to a hardware board. This software typically includes the boot loader, OEM adaptation layer (OAL), and board-specific device drivers.

Catalog

A container of individually selectable units of Windows CE functionality.

component

The smallest unit of functionality that you can add to an OS design.

configuration

A selection of Catalog items and a selection of build options.

hardware platform

A hardware architecture for running a Windows CE OS and associated software.

module

An EXE or a DLL that is a part of a Windows CE OS.

project

A tracking mechanism for a collection of files that you can use to build functionality into a Windows CE OS.

target device, Windows CE–based device

An instance of a hardware architecture or an instance of a combined hardware and software architecture.

workspace

A container for all files related to an OS design.

The following list provides definitions for terms that are sparingly used in Windows CE 5.0:

feature

A comprehensive technology that Microsoft presents as a single entity.

platform

A hardware and software architecture, on a target device, that results from downloading a run-time image to the target device.

The following list shows terms that are not used in Windows CE 5.0 but that were used in earlier versions of Windows CE:

anchored feature, unanchored feature

Windows CE 5.0 refers to Catalog items that you select and Catalog items selected by a design template as user-specified Catalog items.

build release directory

Windows CE 5.0 uses the term release directory. Previous releases of Windows CE use the terms build release directory and release directory synonymously.

custom configuration, platform configuration

Windows CE 5.0 refers to a selection of Catalog items as an OS design, and refers to a selection of Catalog items and build options as a configuration.

development platform

Windows CE 5.0 refers to a hardware architecture as a hardware platform, and refers to an instance of a hardware architecture as a target device.

OS image

Windows CE 5.0 refers to a selection of Catalog items as an OS design, and refers to software to deploy or software already deployed on a target device as a run-time image.

Technorati 标签: wince