What Is Windows CE?
One way to understand the strategic role of an operating system is to examine its design goals. Windows CE is a client platform in the Windows Distributed interNet Applications (DNA) architecture, a framework for building applications that unifies and integrates the personal computer and the Internet. Windows DNA provides an interoperability framework based on open protocols and published interfaces that allows customers to extend existing systems with new functionality such as the Web. Windows DNA applications use a standard set of Windows-based services that address the requirements of the multitiered design of modern distributed applications. Windows CE was designed to be small, portable, and configurable. Let's examine each of these in turn, starting with the first and most important design goal for Windows CE its size.

Hardware Support
The hardware requirements for Windows CE are modest. To run Windows CE, a system must have a 32-bit CPU. The CPU must support paged virtual memory, and must deal with integers in a little-Endian manner. This of course rules out 8-bit and 16-bit processors Windows CE won't ever run on your favorite 6502, or even on a Z80. Sorry. These requirements also rule out the members of the PowerPC processor family that only support big-Endian numbers (although several PowerPC family members, including the Motorola MPC821, MPC823, MPC850, and MPC860, do have little-Endian support and have been validated to run properly with Windows CE). For the Intel x86 family, Microsoft limits support to 486 and faster CPUs.
Processor limitations aside, Windows CE supports the widest range of target processor platforms of any operating system from Microsoft. By comparison, Windows NT today supports two processor families: Intel x86 and Alpha (although it used to support MIPS and PowerPC). Windows CE, on the other hand, supports five processor families, including Intel x86, ARM, MIPS, PowerPC, and Hitachi SH. For a complete list of supported processors, see http://www.microsoft.com/windowsce/embedded/resources/processors.asp.
A practical consideration that arises from support for so many different processors is that you may need to build, test, and ship your software for multiple CPUs. This is primarily an issue for compiled languages like C and C++ since, for example, you cannot run a MIPS-compiled executable (EXE or DLL) on an Hitachi SH processor. But even for interpreted languages like Visual Basic® , Java, and their Web counterparts VBScript and JScript, you should test all of your code on every target platform and on as many of the processors as you can within a given platform.
The presence of multiple target processors creates a particular problem when writing installation programs. Something has to kick-start the installation process; either a person needs to match a CPU/model name to a startup file, or processor-independent scripting code must pick the right binary executable to run. Incidentally, this problem does not exist for the desktop since 16-bit Windows binary executables run on all desktop versions of Windows. Even a Windows NT-based system with an Alpha processor can run 16-bit Windows code, thanks to a built-in emulator that supports the x86 instruction set.
Windows CE does not have this kind of support, so installation programs need a processor-specific version for each processor that you anticipate for your customers. You also, of course, need processor-specific versions of all other executable files. But once your setup code figures out the processor type, the rest is easy.
One solution is to create an HTML setup page that runs JScript code to query the CPU type. The cpuClass property on the navigator object does this nicely:

 if ((navigator.cpuClass.indexOf("x86")>0)
 { // x86 installation code goes here...
 }

Windows CE Tools
To paint a complete picture of Windows CE, I am going to talk a bit about custom embedded Windows CE-based solutions. Along the way, I'll summarize the available tools for writing software for Windows CE. Tools play a role in a custom Windows CE-based solution because of the central role played by one tool: the Platform Builder (see Figure 2). If you have never developed for Windows CE, the following will help you better understand your available choices in terms of languages, and will let you know what specific products you'll need to kick-start your development effort.
Microsoft offers two basic sets of tools to create Windows CE-based applications. You use one set to write application software to run under Windows CE. You use the other set to customize the operating system to run on new platforms, a term Microsoft uses to refer to a specific hardware configuration. For example, a configuration of Windows CE for a digital camera with an NEC VR4121 CPU, a custom ASIC, an optical assembly, a CCD, and supporting circuitry would be a distinctly different platform from a Palm-size PC. The digital camera might have a version of Pocket Internet Explorer, while the Palm-size PC might only have the Channel Browser. Developers of pure application software will use one set of tools; developers who adapt Windows CE for custom hardware will use a different set.
To build applications, you first must decide which language you are going to use. Figure 3 summarizes the languages supported by Microsoft tools. Eventually, Microsoft plans to have all Microsoft-defined platforms (Handheld PC and Palm-size PC devices) support all four of these choices.
At present, only one of the development choices in Figure 3 works on all Windows CE platforms: C/C++ targeted for the Win32 API. This works everywhere because Windows CE itself is implemented with the Win32 API in C and C++. Win32 is so pervasive on Windows CE that even device drivers are written with this API. This contrasts sharply with Windows 9x, Windows NT and Windows 2000 device drivers, which have a completely separate driver interface. Starting with Windows 98 and Windows 2000, a common driver model called the Windows Driver Model will provide the framework for many but not all device drivers. However, Windows CE does not incorporate the Windows Driver Model approach, allowing driver writers instead to directly use the Win32 API.
The availability of the other three choices in Figure 3 depends on the target platform. As far as MFC support is concerned, not every Windows CE platform ships with the MFC DLL. You can still write MFC programs, but you must either statically link to MFC or download the whole MFC library with your application. If you can afford the memory costs, go for it. From the perspective of optimal memory usage, however, it would be better for a device to have the MFC DLL in system ROM than to require using precious RAM to hold it.
Currently, Microsoft provides tools for both Visual Basic-based and Java language applications on Windows CE. Each has components that must be present on a given platform in order to be supported in Windows CE. To run Visual Basic, the Visual Basic runtime library must be present. To run Java applets, you need a Windows CE-compatible Java virtual machine. Visual Basic is becoming more widely available, and some of the recently released color screen Palm-size PCs provide it in ROM but not all of them! So once again, when targeting a specific solution, you need to double-check not only the platform category, but the specific products from specific manufacturers.
For developers who are creating custom Windows CE-based hardware platforms, Microsoft provides the Platform Builder for Windows CE 2.11 or later. The predecessor to the Platform Builder was the Embedded Toolkit (ETK). The Platform Builder contains a version of the Visual C++® 6.0 IDE, and can be used to build applications and download them to a Windows CE-based device. More to the point, this product has binaries and source code to allow the creation of customized versions of Windows CE. Microsoft expects that custom devices will have a device-specific user-interface shell, and so omits from the Platform Builder elements that make up the Handheld PC and Palm-size PC shells, meaning the system toolbar and the desktops.

Browser Support
Starting with Windows CE 2.12, Microsoft is making available three distinctly different ways to view and interact with the Web (see Figure 4). The first, Internet Explorer for Windows CE, is a very fully featured browser that will knock your socks off since it is almost the equal of the Internet Explorer 4.01 on desktop Windows. The second browser is Pocket Internet Explorer, which is the browser that ships with the Handheld PC version 2.0 and the Handheld PC Professional Edition of Windows CE. Finally, the Channel Browser provides a mechanism for users to download push-model Web pages to a Windows CE-based device for offline viewing.

Internet Explorer for Windows CE
The World Wide Web redefined computing in the 1990s, and of course the doorway to the Web is a browser. It has been pointed out often that an average user regards the Internet and the Web as one and the same. Industry insiders know better, of course, but that doesn't change the fact that to demonstrate serious support for the Internet, Windows CE needs a serious browser. Previous versions of Windows CE either lacked a browser or only provided the most basic of browser features. Windows CE 1.0, for example, shipped without any Microsoft browser. And Pocket Internet Explorer (which shipped on Handheld PC devices) was a very functional browser, but it didn't measure up to the sophistication of desktop-based browsers. Starting with Windows CE 2.12, Microsoft can now boast a very serious Windows CE-based browser in the form of Internet Explorer for Windows CE.
With some important exceptions, which I'll detail shortly, Internet Explorer for Windows CE is the equivalent of the desktop-based Internet Explorer 4.01, Service Pack 2. For one thing, the team that created Internet Explorer for Windows CE used the Internet Explorer 4.01 source code as a starting point. In porting Internet Explorer from the desktop to Windows CE, the development team weighed how widely a feature was used against the code size of a given feature. Not everything from Internet Explorer 4.01 made it to Windows CE, but most of the more widely used features did.
One feature common to Internet Explorer for Windows CE and Internet Explorer 4.01 is nearly identical support for HTML 4.0. This is achieved with a common HTML rendering engine, mshtml.dll. In general, the Windows CE version supports the same set of HTML tags and attributes. There are a few subtle differences, however, in how support is provided. One difference is lack of support for data binding. Data binding allows client-side queries to server-side databases. Data binding adds four additional HTML attributes: DATASRC, DATAFLD, DATAFORMATAS, and DATAPAGESIZE. These can be used with a wide range of HTML tags, such as the <TABLE> tag for creating tables that are read directly from a server-based database. The development team for Internet Explorer for Windows CE found that this feature was not widely used with Internet Explorer 4.0, so it was omitted from the Windows CE version.
Internet Explorer for Windows CE supports an implementation of JScript objects and properties that is identical to what you'll find in Internet Explorer 4.01. You will find the expected set of objects, including navigator, window, document, links, forms, and form elements. Standard form elements like buttons, checkboxes, radio buttons, and text input fields are also supported. In addition, you have the standard math and string support. In other words, you've pretty much got a complete JScript implementation. However, anything that relies on features outside pure JScript may not be supported. For example, the ability to run Java applets depends on whether a Java virtual machine is present on a given system.
VBScript is not supported on Internet Explorer for Windows CE. There are two reasons for this: the size of the type libraries and the fact that most Web-based scripting uses JScript. After all, running lean and mean is the primary design goal of Windows CE. At present, VBScript isn't used widely enough on Web pages to justify the cost (the desktop version of vbscript.dll is 417KB) of this component. By comparison, the entire Internet Explorer for Windows CE occupies 3.1MB with all components of that, 1.8MB is mshtml.dll, the HTML rendering engine.

ActiveX Support
Another important feature supported by Internet Explorer for Windows CE is ActiveX® controls. These are, of course, the COM-based modules that can be added onto a Web page as programmable elements. They can have a user interface if you need one, or none if you don't. They are essentially the Microsoft answer to Java language applets. Of course, ActiveX controls on Windows CE are subject to the same limitations as application code: they must work with the subset of the Win32 API that is present on a particular platform.
The process of porting an ActiveX control will depend on how much of the Win32 functionality used by your control is not implemented in Windows CE. Fortunately, finding those functions is as easy as running the compiler and the linker, which will give you a pretty good starting point for determining how much effort could be involved in your whole porting effort. In some cases, there are obvious alternative functions to call. In other cases, you have to choose between rewriting a feature and cutting it. Given the size constraints on Windows CE, cutting features is not a totally unreasonable thing to do.
Of course, porting issues don't end after you resolve all the compiler and linker issues. Subtler differences between Windows CE and the desktop, such as partially supported functions, will still need to be resolved. There is no question, however, that the effort is worth it porting code is almost always faster than writing it from scratch.
Since an ActiveX control is contained in a Windows DLL with CPU-specific executable instructions, you must provide an ActiveX control for each Windows CE-based CPU that you plan to support. One important limitation on this first version of Internet Explorer for Windows CE is that code downloading is not supported. Code downloading is the process by which Internet Explorer handles all the issues associated with moving an ActiveX control from a server to the client computer. The primary reason for this lack of functionality is the size of the code authentication module.
Internet Explorer for Windows CE itself is implemented using COM, just like on the desktop. As with Internet Explorer 4.0, Internet Explorer for Windows CE provides a DLL that implements browser components. On Windows CE, you can create your own Web browser window within your applications by creating instances of these components. With a simple call to CoCreateInstance, you can get your hands on the IWebBrowser2 interface for a browser and provide your own custom Web browsing solution.
Internet Explorer for Windows CE supports Dynamic HTML (DHTML), giving you programmatic control of HTML documents through an embedded scripting language. Since VBScript is not supported, that means JScript is the only language available for your DHTML projects. The full DHTML document object model is supported. So just about all of the objects, properties, methods, events, and collections that you have on your desktop are supported by Internet Explorer for Windows CE.
Cascading Style Sheets (CSS) are supported, with the exception of filters and transitions. CSS allows you to define sets of attributes in a centralized place and assign style tags. When the tag is referenced, the attributes are applied to the associated object. You could have a style with the attribute "bold" to make many different text blocks appear in bold text. By changing the style tag to something else, say "italic," you change all the elements that are tagged with the style. CSS also let new tags inherit attributes from existing tags.
Internet Explorer for Windows CE supports plug-ins, which support features like NetShow!" for the display of streaming video and the multimedia extensions like the Media Player to view AVI files. Technically speaking, these features are not part of Internet Explorer, but of the underlying operating system. While Internet Explorer for Windows CE may have the plumbing for plug-ins, your ability to use them depends on whether a specific plug-in is supported on Windows CE. One very noticeable omission in the Windows CE support for multimedia is support for playing AVI files. So if you have an Internet Explorer 4.01-based solution that makes use of AVI files, that feature will not work under Internet Explorer for Windows CE.

Pocket Internet Explorer
Not every Windows CE-based system needs the full feature set of Internet Explorer for Windows CE, and not every embedded system can afford to spare the required RAM, which is in the neighborhood of 3.1MB (with JScript support, and 2.9MB without JScript). When this is too high a price to pay, a Windows CE system designer can always use the Pocket Internet Explorer. In a minimum configuration without JScript support, as detailed in Figure 5, Pocket Internet Explorer only takes 1.1MB of RAM. Adding JScript support brings the total to 1.3MB, still a far smaller footprint than Internet Explorer for Windows CE.
Pocket Internet Explorer was first introduced with the second generation of the Handheld PC. Prior to the introduction of Internet Explorer for Windows CE, Pocket Internet Explorer was the only browser that Microsoft supplied for Windows CE. (Third parties such as Spyglass also provide a Windows CE-compatible browser.) A significantly improved version ships with the Handheld PC Professional Edition of Windows CE, and this newer version also ships with Platform Builder 2.12.
Pocket Internet Explorer was written from scratch and is not derived from the Internet Explorer code base. Early versions used the HTML viewer control, a Windows CE-specific control that is also used by PEGHELP, the Windows CE help program. Even though later versions don't use htmlview.dll, this control still ships with Windows CE to support third-party applications that need it. To save space, Pocket Internet Explorer and Pocket Explorer are basically the same product with two separate interfaces. When looking at the local file system (when the URL begins with file:), the user interface including menus, toolbars, and the taskbar icon changes to look like Pocket Explorer. When looking outside the file system (when the URL begins with http:, https:, javascript:, or a few others), the user interface displays Pocket Internet Explorer elements. It's worth noting that this behavior matches the behavior of Internet Explorer on desktop Windows.
Pocket Internet Explorer provides support for a basic set of HTML tags, almost equivalent to HTML 3.2. Figure 6 summarizes the HTML tags that are supported on several versions of the Pocket Internet Explorer. The Handheld PC Professional Edition of Windows CE comes equipped with Pocket Internet Explorer 3.0, and this version also ships with Platform Builder 2.12.
In its latest incarnation, Pocket Internet Explorer supports JScript, but not VBScript. The JScript object model in Pocket Internet Explorer is roughly equivalent to that provided in Internet Explorer 3.02. It is, however, by no means a complete implementation of Internet Explorer 3.0. From within JScript, the navigator object reports its appVersion property to have the following value:

 2.0 (compatible; MSIE 3.02; Windows CE)

 if ((navigator.appVersion.indexOf("MSIE 3.02")>0 &&
     (navigator.appVersion.indexOf("Windows CE")>0)
 { // PIE on HPC Professional Edition
 }

Channel Browser
The smallest, simplest Windows CE browser is the Channel Browser. The Channel Browser was first introduced with the Palm-size PC, although you can also download a version for the Handheld PC and Handheld PC Professional Edition versions of Windows CE from the Microsoft Web site. The Channel Browser lets you view Web-based content that has been explicitly formatted to accommodate the small screen size and memory space of a Windows CE-based device. The Channel Browser is essentially an extension of the Active Channel!" feature of Internet Explorer 4.01, which works with Web sites that have been set up to download push content. A push site specializes in providing a specific type of data, such as stock quotes, sports scores, or the daily news. On Windows CE, the basic model has been enhanced to allow a store-and-forward model for new data. A PC connected to the Internet accepts the data as a proxy for the Windows CE-based device. When this device is connected, the Active Sync support libraries step in to download all the new data to the Windows CE device for browsing when the device is disconnected from its PC.
The Channel Browser doesn't ship with the Platform Builder, so you won't see it used on custom Window CE-based solutions. Instead, it only runs on PC Companion devices. To determine whether channel browser support has been downloaded to a device, check for the files aaview.exe and aatp.dll.

Conclusion
With the introduction of Internet Explorer for Windows CE, Microsoft has taken a huge step forward in browser support for this system. While its predecessor, the Pocket Internet Explorer, provided basic Web browsing features, Internet Explorer for Windows CE has pushed the level of Web browsing support on Windows CE almost to the equal of desktop Windows. The availability of both products means that all Windows CE-based systems can provide browsing support. The inclusion of these products in the Platform Builder allows developers of custom Windows CE-based systems to access to all that Windows CE offers.

http://msdn.microsoft.com/library/tools/mobchan/mc_res_1.htm http://www.microsoft.com/windowsce/developer/

From the May 1999 issue of Microsoft Internet Developer. Get it at your local newsstand, or better yet, subscribe.