Platform Basics in Windows CE
- Platform Builder Basics
- Creating a New Platform with the Platform Wizard
- Building and Executing the Platform
- Creating Applications for Your Platform
- Running Windows CE on a CEPC
- Integrating New Components into the Image
- Customizing the Build Using Environment Variables
- Extending the Platform Builder Catalog
- Creating a New Board Support Package
- Summary
The goal for Windows CE is to be able to run in a variety of devices and appliances. If you stop and think for a moment, you will realize that the world of consumer electronics is home to an array of devices that have wildly fluctuating hardware architectures. It would be hazardous to make assumptions about the processor, processor speed, available RAM, and storage medium on any given device. Can a tiny handheld digital telephone make room for a Pentium processor? Does it make sense for a refrigerator to have a hard disk? What's an operating system to do?
Microsoft has attempted to resolve these issues by making Windows CE a component-based operating system. A few of the basic OS functions are mandatory and must be supported by any hardware device that intends to use Windows CE. Everything else is up for grabs; you can add it to your operating system, or you can leave it out.
What exactly are these components? A component is a particular functionality that can be integrated into or left out of Windows CE. Components are available in the form of drivers, static or dynamic libraries, and executables. Windows CE can be built with selected components that are appropriate to the platform being developed. The tool that is used to build modified versions of Windows CE is called Platform Builder. Platform Builder is a set of CDs that contain utilities, files, and the components of Windows CE. Components can be platform dependent or platform independent. An example of a platform-dependent component is the kernel for an x86 PC. A component that allows the user to calibrate the touch panel and saves the coordinates is an example of a component that is platform independent. In addition, a component usually has a distinct resulting build targeteither an executable or an object module library.
Let's look at the concept of a module. Several components can be linked together to form a module. A module is an executable or library file that performs a set of well-defined operations and exports a well-defined API. A module is divided into components according to areas of functionality, although such division is historically restricted by how the code was written. Microsoft has done its best to separate the modules into components in such a way that OEMs can select only the functionality they need for their platform. On value-priced consumer devices with multiple form factors, this is a critical feature. However, not all modules can be broken down into components.
Exploring Components in Platform Builder
Now that we have an idea of what components are, let's look at the real situation in the Platform Builder IDE. If you start Platform Builder and wait for it to open its main window, you will see all components collected in a Catalog window (Figure 3.1).
Platform Builder Catalog
The Catalog window in Platform Builder lists all the components that are available for inclusion in your build of the operating system. To create a custom version of Windows CE, also referred to as a build, you must create a project in Platform Builder. Note that Platform Builder terminology dictates that a component in the Catalog window is referred to as an implementation. When the implementation is included in a project, it becomes a component. An implementation is depicted by the icon shown in Figure 3.2. Implementations are grouped together by functionality into categories, or types. Types are depicted by the icon shown in Figure 3.3. An example of a type is display, which groups together available display drivers in a platform.
The types can be traversed and viewed just like a folder hierarchy. The implementations contained in the types and folders of the default catalog (see Figure 3.1) opened by Platform Builder are presented in Table 3.1. You can extend the default catalog view by adding components of your own. We'll say more about that later in the chapter.
Table 3.1 Types and Implementations in the Default Catalog
Folder |
Configuration |
Type |
Implementation |
Description |
coreos |
|
|
|
A folder that contains sample configurations of the operating system. |
|
IESAMPLE |
|
|
A sample configuration that includes almost all available components and adds the Internet Explorer Web browser control. Full localization is supported, and the Input Method Manager (IMM) is also included. |
|
MAXALL |
|
|
A sample configuration that includes almost all available components, including the shell and Pocket applications. |
|
MINCOMM |
|
|
A sample configuration that includes a minimal set of components and adds serial communications and networking. |
|
MINGDI |
|
|
A sample configuration that includes a minimal set of components that can support the Graphical Device Interface (GDI). No window support is provided, but you can use GDI calls to create a minimal user interface if required. |
|
MININPUT |
|
|
A sample configuration that includes a minimal set of components that can support user input via the keyboard. A display |
|
|
|
|
driver is included, but GDI is not supported. |
|
MINKERN |
|
|
A sample configuration that contains the operating system kernel and a "Hello World!" application that outputs text to the debug serial port. This is a good first configuration to use when you're booting a platform with Windows CE. |
|
MINSHELL |
|
|
A sample configuration that is very much like MAXALL without the Pocket applications. |
|
MINWMGR |
|
|
A sample configuration that includes components that can support the window manager. Full networking support is included. |
Drivers |
|
|
|
A folder that contains platform-specific device drivers. |
|
CEPC |
|
|
A folder that contains device drivers for the CEPC platform, which supports the x86 family of processors. |
|
|
display |
|
Display drivers type. |
|
|
|
Ddi_ct |
Display driver for Chips & Technologies CT6555x chip set. |
|
|
|
Ddi_364 |
Display driver for the S3 Trio64 chip set. |
|
|
|
Ddi_s3v |
Display driver for the S3 ViRGE chip set. |
|
|
|
Ddi_vga8 |
A simple VGA display driver for eight-bits-per-pixel displays. A good first choice when testing a display adapter on a CEPC or any other platform that supports a VGA-compatible display. |
|
|
kbdms |
|
Keyboard and mouse drivers type. |
|
|
|
Kbdmsengus1 |
Driver for U.S. English keyboards. |
|
|
|
Kbdmsjpn1, |
Drivers for Japanese keyboards. |
|
|
Kbdmsjpn2 |
|
|
|
|
nscirda |
|
Infrared driver. |
|
|
ohci |
|
Universal Serial Bus (USB) host controller interface driver. |
|
|
pc_ddk |
|
Hardware Abstraction Library (HAL). |
|
|
|
Ddk_bus |
Implementation of routines to abstract bus I/O (input/output). |
|
|
|
Ddk_map |
Implementation of routines to abstract memory I/O. |
|
|
pcmcia |
|
PCMCIA driver. |
|
|
serial |
|
Serial port driver. |
|
|
sermouse |
|
Serial mouse driver. |
|
|
wavedev |
|
SoundBlaster AWE64 PNP ISA driver. |
|
|
eboot |
|
Ethernet debugging library and helper routines for creating an Ethernet boot loader. |
|
ODO |
|
|
Device drivers for the Hitachi D9000 (Odo) platform, which supports multiple processors. |
OAL |
|
|
|
OEM Abstraction Layer type. This is a platform-specific layer of code that is created by the OEM. |
|
CEPC |
|
|
OAL for the CEPC. |
|
ODO |
|
|
OAL for the D9000. |
Platform |
|
|
|
A folder that contains Platform Manager |
|
|
|
|
Manager client components. These components are used to provide a communication channel between Platform Builder and the operating system being developed on the platform. |
|
Cemgrc |
|
|
Platform Manager client. This component manages high-level communication between the Platform Builder (cemgr.exe) and the operating system running on the platform. |
|
Transport |
|
|
Transport component type. A transport component is the protocol to be used between Platform Builder and the Platform Manager client. |
|
|
pm_ppp |
|
PPP protocol used as transport. |
|
|
pm_tcpip |
|
TCP/IP protocol used as transport. |
|
|
pm_cesrv |
|
Windows CE services transport. |
Runtimes |
|
|
|
A folder that contains runtime environments for Windows CE application development. |
|
Adoce |
|
|
A configuration that contains ActiveX data objects for Windows CE. |
|
VB |
|
|
A configuration that contains components for Visual Basic runtime support. |
|
|
vbeng |
|
Visual Basic runtime engine. |
|
|
vbforms |
|
Support for forms. |
|
|
controls |
|
Visual Basic controls. |
|
|
|
MSCEComDlg |
Common dialog control. |
|
|
|
MSCEComm |
Support for common controls. |
|
|
|
MSCECommandBar |
Command bar control. |
|
|
|
MSCEFile |
File I/O control. |
|
|
|
MSCEGrid |
Grid control. |
|
|
|
MSCEImage |
Image control. |
|
|
|
MSCEImageList |
Image list control. |
|
|
|
MSCEListView |
List view control. |
|
|
|
MSCEPicture |
Picture control. |
|
|
|
MSCETabStrip |
Tab control. |
|
|
|
MSCETreeView |
Tree view control. |
|
|
|
MSCEWinSock |
A control that supports the Windows Socket API. |
|
VC |
|
|
A folder that contains components for Visual C++ runtime support. |
|
|
mfc |
|
Runtime component for Microsoft Foundation Classes. |
|
|
atl |
|
Runtime component for Active Template Library. |
Now that we have these components in a catalog, what can we do with them? Components are reusable objects and can be added to any project. The best way to illustrate the use of the catalog is to create a sample project. As we discussed in Chapter 2, the best place to start is to run Windows CE on a PC. For our first Windows CE build, we'll create a special build of the CEPC based on MAXALL called Adam. A special build of Windows CE is referred to as a platform.