A Taste of Talisker
November 6, 2001
Welcome to the first edition of MSDN's Get Embedded column. We're super excited to be writing about such cool technologies. We have a great line up of articles planned for the next few months—and we do, of course, also value article suggestions from you, our readers, so please send us your feedback. Okay, then, let's get cracking with article #1 …
This initial article is designed to bring everyone up to speed with a brief history of Microsoft® Windows® CE, and a description of the tools used to build and configure this remarkable operating system. We do, of course, plan to get deeper and more technical in subsequent articles.
So What Exactly Will the Get Embedded Articles Cover?
You're probably aware that Microsoft currently ships three embedded operating systems—Windows CE 3.0 and Microsoft® Windows NT® Embedded 4.0 being the most visible of the three. Both these operating systems are being updated. The next version of Windows CE is known by the codename "Talisker." The next version of Windows NT Embedded is Windows XP Embedded. This column, then, will focus on how to build embedded systems using Talisker and Windows XP Embedded.
Hey, hang on, what about the third operating system? The third operating system is Windows for Smart Cards, an 8-bit operating system exposing approximately 30 APIs that make it very easy for developers to build custom smart card solutions. You can find more information on Windows for smart cards at http://www.microsoft.com/smartcard/.
We're not planning on covering application development for devices such as the Pocket PC, since this subject is already covered by the Two for the Road column. Neither will we cover application development for Windows XP Embedded, since application development for Windows XP is covered at length in other articles/publications. We will, however, discuss application development if the subject matter relates to building an embedded system, or to porting desktop application code to an embedded environment.
Before we get started with first looks at Talisker (next month), let's kill some myths and give some context for Talisker by providing a brief history of Windows CE. (Note that articles covering Windows XP Embedded will be published in this column a couple of weeks after Windows CE articles, and will be authored by the wild man of the West, Jon Fincher. Stay tuned for more information.)
Can't CE the Wood for the Trees? (Or, a Brief History of Windows CE)
The first device using Windows CE was the handheld PC 1.0. This shipped in 1996, and used Windows CE 1.0. At the time, there weren't any publicly available tools to allow developers to build their own custom-embedded devices using Windows CE, though we did ship a set of tools to hardware OEM's building the handheld PC 1.0 (Casio and Compaq). These tools were known as the OEM Adaptation Kit, or "OAK."
From that point forward, new releases of the Windows CE operating system were given codenames based on trees: Alder (Windows CE versions 2.0/2.1), Birch (Windows CE Versions 2.11/2.12), and Cedar (Windows CE 3.0). The tools used to build the operating systems were named after tools that cut down trees: Axe, Buzzsaw, and Chainsaw. Now we're getting set to release the next version of Windows CE, named after that well known tree, Talisker. (Hang on, this isn't a tree. It's a Scotch whisky.) Why the name change? We've now combined the operating systems and tool projects, and have therefore chosen a new naming scheme for the product—after whiskies.
|CE Version||Date||O/S Code Name||Tools Code Name||Shipping Tool Name|
|2.0||'98||Alder||Axe||Embedded Toolkit 2.0|
|2.1||'98||Alder Enhancement Pack (EP)||Axe Enhancement Pack (EP)||Embedded Toolkit 2.1|
|2.11||'99||Birch||Birch||Platform Builder 2.11|
|2.12||'99||Birch Enhancement Pack (EP)||Birch Enhancement Pack (EP)||Platform Builder 2.12|
|3.0||'00||Cedar||Chainsaw||Platform Builder 3.0|
|Talisker||---||Talisker||Talisker||Windows CE .NET|
I've heard a number of times and from a number of sources that Windows CE is a cut-down version of Windows 95 or Windows NT. I guess this assumption exists because the UI of the first Windows CE devices was very similar to Windows 95, and also exposed Win32 as a programming interface.
This is, however, nowhere near the truth. Windows CE is an operating system built from scratch and specifically designed for the needs of embedded systems.
Windows CE has had a number of design goals from day one. These include:
- Building an OS suitable for small systems.
- Supporting a broad range of hardware.
- Using standard APIs, programming models, and tools.
- Making the OS componentized and ROM-able to allow for the best fit of memory and features.
- Enabling compelling products with built-in features like communications, user interface, database, and file systems.
- Real-time support.
- Enabling battery-powered products by including unobtrusive power management.
Let's briefly examine how Windows CE delivers on each of the above points.
Building an OS suitable for small systems. The minimum build size for a Windows CE operating system image is around 400 KB. This grows as a developer adds functionality and modules to their device image. A typical image size for a handheld device is on the order of 8 MB. This includes a Windows 95-like shell, a Web browser (compatible with Microsoft® Internet Explorer® 4.0), an e-mail client, and Microsoft® Pocket Word.
Supporting a broad range of hardware. Windows CE supports a range of processors and a range of hardware reference platforms. It is also possible to port Windows CE to a new hardware reference platform (more on this in the coming months). For a complete list of supported processors and hardware reference platforms, check out Hardware Support and Device Drivers.
Using standard APIs, programming models, and tools. Windows CE exposes the Win32 API. This makes it easy for developers that already program for the Windows desktop to start developing applications for a Windows CE platform. Windows CE 3.0 exposes roughly 2000 APIs. Compare this to the 20,000 APIs exposed on Windows 2000. There are a number of reasons why we only expose about 2000 APIs. For example, we don't support MS-DOS or Windows 3.x programs; nor do we support some of the larger API sets of Windows desktop, such as ODBC (we do, however, support databases) and OLE (although we do expose the 'O' [objects] through COM/DCOM).
We've also examined the list of APIs exposed on desktop Windows and have made a decision about which APIs should be exposed on Windows CE. For example, to draw a line using Win32 API calls on Windows 2000, I can call MoveTo(x,y) to set the start point of the line and then call LineTo(x,y) to draw the line. Alternatively, I can call PolyLine(&pts,nItems), which takes an array of points. On Windows CE, we only expose PolyLine( ) (although MFC on Windows CE still exposes the MoveTo/LineTo functions, which simply call down to PolyLine). Windows CE supports all of the great programming models you know and love on the desktop, such as MFC, COM, ATL, and Microsoft® Visual Basic® programming.
Making the OS componentized and ROM-able. Windows CE 3.0 is made up of 220 modules (a module can be considered to be either an EXE or a DLL). Each of these modules is further subdivided into components (LIB files), making Windows CE highly configurable. As an example, consider just one of these components, GWES (Graphics, Windowing, and Event Sub-system), which is made up of over 90 components, including support for raster or True Type fonts, touch and calibration UI components, and so on. Over the next couple of issues, we will explain how to select the components for your device.
When building the operating system, you can decide to build it either compressed or uncompressed. An uncompressed image that resides in ROM or Flash can execute in place (XIP), without needing to be loaded into RAM. An image built in a compressed form, however, cannot execute in place. It's possible to load the operating system from storage media (such as a CF Card, or disc drive) into Ram and execute in Ram, and we also ship a sample Dial-Up Bootloader (DUB) that allows devices to remotely load their operating system image.
Real-time support. A real-time operating system is just one element that contributes to the overall real-time performance of a device; hardware and applications also play a part. Although previous versions of the Windows CE operating system offered some real-time capabilities, a number of significant changes made to the kernel of Windows CE 3.0 have greatly enhanced real-time performance. For a complete discussion of the changes made in the Windows CE 3.0 operating system, take a look at the articles and online seminars on the Windows Embedded Home Page.
Enabling compelling products. Device manufacturers have a number of choices when building their devices. Windows CE exposes a range of technologies, including:
- Display: "headless," touch screen, regular display, and black and white through-to devices running at 32 bits per pixel (bpp).
- Communications: serial, Telephony API (TAPI), Internet Connection Sharing (ICS), PPTP, IrDA, TCP/IP, FTP, HTTP, DCOM, Web Server, UPnP, SNMP, Remote Desktop Protocol (RDP), and so on. For devices that cannot guarantee the uptime of the network, local database storage using Microsoft® SQL Server 2000 Windows CE Edition, or Microsoft® Messaging Queue (MSMQ) are also options.
- Database: CE Database APIs (Win32), OLEDB, ADOCE, SQL Server 2000 Windows CE Edition.
- Browsers: HTML 3.2 Browser or Internet Explorer 4.0 compatible browser. The Internet Explorer browser ships as an ActiveX® control (and also supports hosting of ActiveX controls), so it can be embedded into your own application—or, it can become the shell of your device. (The IESAMPLE application in Platform Builder shows how to embed the browser into an application. More on creating custom shells over the next few months.)
- Localization: National Language Support (NLS). Windows CE is based on Unicode and therefore is capable of supporting a range of languages. It ships with operating system support for Dutch, English, French, German, Italian, Japanese, Korean, Portuguese (Brazilian), Spanish, and Swedish.
- Multimedia: Windows CE 3.0 exposes support for DirectX, including streaming of multimedia over TCP/IP, DirectShow, DirectDraw, and DirectSound.
Unobtrusive power management. Windows CE provides power management to reduce energy consumption and lengthen the life span of the system's batteries (although Windows CE devices can also run on mains power). To manage power, Windows CE uses the following running states:
- No Power. In this state, the CPU is off and no power is supplied to RAM. All platform devices are off.
- On. This is the standard running mode. The CPU is running, and it schedules threads. RAM and all platform devices are powered.
- Idle. In this state, no threads are running, and the CPU is in a suspended mode in which it manages only interrupt exceptions. RAM is powered to maintain all its values. All platform devices are on.
- Suspend. In this state, no threads are running, the CPU is in a suspended mode, and the timer interrupt is stopped. RAM is powered to maintain all its values. All platform devices are off.
- Critical Off. In this state, the CPU is suspended. RAM is in a self-refresh state to consume as little energy as possible. All platform devices are off.
So, Exactly How Does Windows CE Relate to the Handheld PC and Pocket PC Devices?
Great question. I'm glad you asked. The Windows CE operating system is somewhat like a bucket of LEGO® building blocks—it's possible to build a wide variety of things using LEGO blocks; you're only restricted by your imagination. For instance, let's say you want to build a car using LEGO pieces. You would need wheels, a vehicle body, possibly a motor, one or more drivers (and of course Windows).
When building your LEGO car, you only use the appropriate blocks from the LEGO tub. This is also true of building an embedded device using the Windows CE operating system. Windows CE is componentized; as an embedded developer, you get to choose the blocks or components of Windows CE appropriate for your device (componentization was one of the core design goals of the Windows CE operating system). It is therefore possible to build a wide variety of devices using the Windows CE operating system, including industrial control systems, handheld and Pocket PCs, set-top boxes, and so on.
Pocket PC uses the Windows CE 3.0 operating system; this can be verified by taking a look at the "About" control panel applet on the Pocket PC (screenshot below). In effect, the Pocket PC team have taken the appropriate "blocks" or components of Windows CE that make sense for their device, have added their own applications and technologies—such as e-book Reader, Media Player, Pocket Word, Soft Input Panel [SIP], custom Shell, and so on—and presto! We have a new device category called the Pocket PC, based on Windows CE 3.0.
Figure 1. The "About" control panel applet on the Pocket PC
I've highlighted the Windows CE version number on the "About" Control Panel Applet. This clearly shows that Pocket PC is running Windows CE 3.0. Note that this snapshot was taken using the Remote Display "powertoy," which can be downloaded from the Pocket PC Web site at Pocket PC Downloads.
We already know that the Windows CE 3.0 operating system contains around 220 modules; using the Platform Builder 3.0 tool, I can configure a custom image of Windows CE 3.0 by selecting the components that make sense for my device—if I want to, I can include a Web Server, support for DCOM, and so on. The Pocket PC team has been through the same process of determining which components of Windows CE 3.0 make sense for their specific implementation of Windows CE 3.0. Therefore, not all components of the Windows CE 3.0 operating system exist in the Pocket PC.
Windows CE Tools
Now that we've described how the OS is modular and contains many components, the question that naturally arises is: "How can I customize the OS for my device?" Well, that's where the tools come into the picture. There are two primary tools for developing with Windows CE for embedded systems—Microsoft® eMbedded Visual C and eMbedded VisualC++® (eVC) and Microsoft® Windows CE Platform Builder. (There is also eMbedded Visual Basic®, but that's not used much for embedded development, so we won't really be talking about that here.) There is some confusion on the capabilities and use of each tool, so let's clear that up right up front.
eMbedded Visual C/C++
The compilers for all the CPUs supported by Windows CE are included with eMbedded Visual C++ (eVC). The eVC installation also includes optional SDKs for most of the retail devices. The SDKs include all of the header files and libraries needed for building an application to run on a specific device. eVC supports MFC and ATL for Windows CE, and there is a complete remote debugger and a set of remote tools—like the remote process viewer and remote registry editor—that are of great value when working with applications development.
Ok then, what's this Windows CE Platform Builder thing for? Well, as the name implies, Platform Builder is used to build new platforms that utilize the Windows CE operating system. OEMs use Platform Builder to select the modules and components for their custom build of the OS. Platform Builder is also used to develop and debug Device Drivers. Platform Builder includes a remote debugger as well. The debugger in Platform Builder, however, is a kernel-level debugger. That is, it operates internally as part of the OS kernel, and is initialized at a very early stage of the system startup. This allows OEMs to debug device drivers remotely, including serial port drivers and/or Network drivers used to transport the messages the eVC application debugger uses.
This is a powerful capability, essential to an OEM bringing up the system for the first time on a new platform. As of Platform Builder Version 3.0, there is also an eXtended Debugger Interface (eXDI) that allows for plugging in support for hardware-level debugging. eXDI is used from the IDE to connect the IDE debugger to an In-circuit emulator or an On-chip debug port (assuming you have the appropriate JTAG/BDM pods to do that). Using eXDI you can have the full IDE debugger support with source-level debug capability, starting at the processor rest location.
Another major element of Platform Builder is the ability to generate an SDK for the customized version of the OS. Applications developers can install an SDK generated by Platform Builder and they can then use eVC to write applications for that platform. Talisker includes the really cool capability of including an emulation environment for the SDK. The emulation allows developers to write applications and test them out on a real OS build, running on a CPU/hardware emulation system. This means application development can start well before the first prototype of the hardware is available. This is an exciting feature of the tools, and we'll get into this in greater detail in future articles.
These features only scratch the surface of what Platform Builder can do. We'll dig into the details in future articles, but this should serve to differentiate the tools and clear up what each is used for.
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.