You now have three ways to surf the Web from your Windows CE device: the Channel Browser, Pocket Internet Explorer, and Internet Explorer for Windows CE. Each supports different browser features, so it pays to know what you're targeting with your mobile app.

By now you've probably heard of Windows® CE, but you might still be wondering what it is and how it differs from other Microsoft operating systems. And since you're reading MIND, you're almost definitely wondering whether Windows CE can connect to the Internet or corporate intranets. It can, but the support it provides is different from what you get with desktop versions of Windows.     I'll start by describing the basic goals of Windows CE, and outlining the available Windows CE-related tools. Some of this will be a review if you've already delved into Windows CE, but it is necessary to help explain how some of the Internet-related components are being made available. The second half of this article focuses on what support you can expect for Internet connectivity in Windows CE in the form of supported browser technology. I'll look at the Channel Browser, Pocket Internet Explorer, and a new version of Microsoft Internet Explorer planned for release in April: Internet Explorer for Windows CE. 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.

The Windows CE Desktop

    Windows CE was created to fill a niche at the low end of the spectrum of microprocessor-powered devices. It is not intended as a replacement for either Windows 98 or Windows NT®, but rather as a small operating system that supports a subset of the features of its larger siblings.

    One way to compare Windows CE to desktop versions of Windows is by the number of supported Win32® API functions. Windows CE 2.0 for the Handheld PC supports 850 of the 2500 or so Win32 functions found in Windows NT 4.0. Some features—including kernel features like DLLs and threads—are the same as their desktop equivalents. Yet other features are omitted entirely, such as security, Dynamic Data Exchange (DDE), DCOM, DirectX®, MAPI, OpenGL, hooks, Image Color Matching (ICM), and the ability to play AVI files. Microsoft is continually working to add new API support to Windows CE, as it sees the need for new features or support for old APIs. For example, support for the encryption API—functions with the prefix Crypt such as CryptEncodeObject and CryptDecodeObject—was added in Windows CE 2.1.

    Since Windows CE is targeted toward small systems, it's not surprising that its most important design goal is to be small. The core Windows CE operating system components occupy a scant 2.5MB footprint on a Handheld PC. That is tiny when compared to the tens of megabytes required for Windows 95 or Windows 98, and the hundreds of megabytes needed for Windows NT. It is so small that a typical Windows CE system has no hard drive (the file system resides in RAM) and is battery operated. Although this represents the typical system, I should also point out that it is possible to create a Windows CE-powered system that has hard drives and that runs on AC power.

    A second key design goal for Windows CE is portability. This means several things. First, the operating system itself can run on a wide range of processor platforms. Second, that existing Win32 code can be ported from desktop Windows-based systems with some degree of ease, so the level of portability depends on exactly what you want to do.

    Porting desktop code to Windows CE involves a trade-off between working around unsupported APIs and fitting your software into the limited RAM and ROM of your target device. This is an issue because a typical Windows CE-based unit has a tiny memory footprint compared to most desktop systems. The Handheld PC Professional Edition device that I have on my desk—and on which, thanks to Pocket Word, I am writing this article—has 16MB of RAM, 16MB of ROM, and no hard drive. By the standards of Windows CE, this is a hot-rod configuration!

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_list.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...
 }

    The third design goal for Windows CE is configurability. Unlike desktop versions of Windows, which always come with a static set of applications and libraries, Microsoft designed Windows CE so that creators of new Windows CE-based platforms can customize the operating system itself. The ultimate goal is to do a specific set of tasks very well and to consume a minimum of hardware resources while doing so. Windows CE gives system implementors the flexibility to include only the modules that they need and to exclude unnecessary modules.

    Try to imagine a version of Windows 98 without support for the File/Open dialog box or a version of Windows NT without a Control Panel. While such omissions might make a programmer of desktop Windows-based systems uncomfortable, they are the rule of the day with Windows CE. With few restrictions, system builders can assemble the 100 or so Windows CE modules into whatever configurations they need.

    While this flexibility is helpful to system builders, it can create some frustration for application developer since few blanket statements can be made about what you'll always find on a Windows CE-based system. In the context of Internet programming, this means there will be Windows CE-based systems that run without any browser support, or with a minimal browser configuration that might not include features you want or need. For example, the ability to run Java applets requires the presence of a Java virtual machine, which won't necessarily be available on all Windows CE-based systems. In practical terms, when you are assembling a Windows CE-based solution, you have to take a close look at the available features on your specific target platforms.

    While you may find variation in the hardware and software configurations of different Windows CE platforms, Microsoft has defined a set of platforms known as PC Companions. These describe categories of products that are based on a specification created and enforced by Microsoft. These are products intended for mass-market distribution, and as such provide a relatively stable set of features. Figure 1 summarizes the publicly available platforms for the Microsoft targeted PC Companion devices. In describing Internet support provided by Windows CE, I will use these products as landmarks.

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.

Before delving into the details of these three browsers, I must point out that both Internet Explorer for Windows CE and Pocket Internet Explorer are available as part of Platform Builder version 2.12. This is noteworthy for several reasons. First, the high-octane Internet Explorer for Windows CE will not work with previous versions of Windows CE. The current crop of Windows CE-based PC Companion devices don't have this browser, and you cannot simply download the new browser to older devices. Several new Win32 APIs were added to Windows CE to support Internet Explorer for Windows CE. The good news is that the creators of the next generation of Handheld PC and Palm-size PC devices—those built around Windows CE 2.12 and later—will have access to this new browser. I expect many of them will choose to incorporate it in their new devices.     The inclusion of these two browsers in the Platform Builder is noteworthy for another reason. If you are building a custom Windows CE-based platform, starting with version 2.12 you get two browsers to choose from for your device. Even though Pocket Internet Explorer was available in previous versions of Windows CE, it was not made available for inclusion in custom Windows CE systems. 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 3.2. 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 2.5MB with all components—of that, 1.5MB 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 2.5MB. 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 71KB of RAM. Adding JScript support brings the total to 413KB, 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) Within an HTML page, you could check for this version of Pocket Internet Explorer with a JScript sequence like the following: if ((navigator.appVersion.indexOf("MSIE 3.02")>0 && (navigator.appVersion.indexOf("Windows CE")>0) { // PIE on HPC Professional Edition } Some versions of Pocket Internet Explorer didn't support any JScript. To handle such cases, you'd have to make sure the structure of your HTML degraded gracefully for non-scripted browsers. Toward that end, Pocket Internet Explorer is generally more forgiving than other browsers, and tends to not complain. The problem, of course, is that you don't get the error reporting that desktop browsers give you, and so debugging problems in your HTML is much harder.     Pocket Internet Explorer is a very scaled-down browser compared to Internet Explorer for Windows CE. Pocket Internet Explorer does not support ActiveX objects, DHTML, CSS, plug-ins, VBScript, or the Java language. There is also no support for data binding or XML. But if you need to integrate a small, forgiving browser into an embedded Windows CE solution, Pocket Internet Explorer could be the ticket. If you need something with richer features that approach the support you find in desktop browsers, then Internet Explorer for Windows CE might be a better choice. 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://www.microsoft.com/windowsce/developer/

From the May 1999 issue of Microsoft Internet Developer.