Windows CE has built-in support for Internet protocols, but because it was
designed for diskless systems, many things have been left out. Here’s what comes standard and what you can do with it.
As a relatively young operating system, Windows CE doesn’t quite have the level of Internet support provided by other operating systems. But because the Internet is such an obviously important part of today’s computer technology, Microsoft’s Windows CE development team has been working overtime to add new features to each version. The results are a
relatively small operating system with a reasonable degree of Internet-support punch. With all of its Internet support, Windows CE could form the basis for a “Network Computer” (a small, inexpensive device that relies on network servers for most storage) that some in the industry have predicted.
Smallness: the defining constraint
Windows CE has constraints that will probably prevent it from ever having all of the features of larger operating
systems. In particular, Windows CE was built to be a small operating system. In the context of Windows CE, “small” means being able to run in a memory footprint of 4MB to 16MB. At first glance, this doesn’t seem like an ambitious goal. Sixteen megabytes, after all, is a lot of memory. Quite a few older Windows 9x systems, for example, have this much memory.
What makes this constraint challenging is the fact that in Windows CE, RAM serves as both file storage and program memory. In other
words, in a Windows CE system with 16MB of RAM, not all of that memory is used for running programs. Such a system could be configured, for example, to use 8MB for its filesystem (part of its “object store”), which would leave 8MB for program memory.
The filesystem is often supplemented by ROM (or flash RAM) for the operating system and for the storage of other static components such as data files and application software. Adding 8MB of ROM brings total available memory to a whopping 24MB! If
you’re used to working with desktop systems, you probably can’t imagine having such little storage space. If you’re used to working with embedded systems, you probably can’t imagine having so much.
What is large and what is small, of course, depends on what you are accustomed to. In the good old days of Windows 1.x (circa 1985), a typical Windows machine had 640K of RAM and two 360K floppy diskette drives. From the perspective of those days, when Windows ran with a total memory capacity
(RAM plus disk) of 1.3MB, a memory budget of 24MB seems like a king’s ransom. Throw in today’s faster processors, and it becomes obvious that although a typical Windows CE system is smaller than today’s desktop systems, it easily has enough oomph for a wide range of demanding applications.
Here’s another perspective, with a somewhat Darwinian edge. The constraint on system size may ultimately benefit Windows CE users, and indeed all computer users. The need to scale back on features
to fit into a small memory footprint may force software companies to give thorough consideration to what features get cut and which ones get kept. Only the best, most widely used features of a given software package will make it into the Windows CE version. In a world where succeeding generations of software have routinely added more and more new features—what some call feature creep or “creeping feature-itis”—only a small subset of all the capabilities of today’s application
software will make it into the Windows CE version. Software archeologists may someday point to Windows CE and its small memory footprint as the start of a movement to put the appropriate amount of features into software.
But enough on software philosophy. You are reading this because you are interested in Internet programming in Windows CE. I’ve framed this discussion around the types of devices that can run Windows CE, and will discuss supported Windows CE devices next.
Types of Windows CE devices
A discussion of Windows CE devices is necessary because not every Windows CE device is the same. Computers that run Windows 95/98 and Windows NT tend to have the same basic set of hardware. Creators of Windows CE platforms, on the other hand, have more latitude in the design of system hardware. For example, desktop Windows systems always have a keyboard and a display screen, and such systems interact with a user through a graphical user interface. A
Windows CE system, on the other hand, could be created without any user input device but instead run as a “headless” system. Or, it might interact with its user through a character-based user interface.
While you can speak of Windows CE as if it were some kind of monolithic operating system, it is in fact highly configurable. Windows CE system builders have a great degree of flexibility in how they configure the operating system itself. Using a tool called the Platform Builder, a development
team can create a custom version of Windows CE. This greater flexibility means that it’s possible to deploy a Windows CE system with none of the features that I describe in this article. In this day of Internet-mania, it might seem strange to discuss deploying unconnectable devices. However, that is a choice that a system development team could make, and the Windows CE Platform Builder fully supports that option. If you are writing software for a device that runs a custom version of Windows CE,
you’ll need to double check the exact set of Internet features contained on that device before you begin designing and developing your software.
Windows CE devices come in two broad classes: Companion PC devices and custom devices. Microsoft has defined the basic hardware and software that make up each of the devices in the Companion PC device class. System implementors have much greater flexibility in defining the hardware and software makeup of the second class of devices, the custom devices. It is with
the latter category that you must be careful to check out the support provided early in your software development project.
The Companion PC device class can be organized into three main categories: the Handheld PC (HPC), the Palm-size PC, and the AutoPC. The HPC is like a mini laptop computer, with a keyboard, a screen, and a variety of I/O devices. The Palm-size PC category has a screen (240x320) but no keyboard, and is meant to fit in a shirt pocket. The AutoPC is a car stereo replacement that combines
all the features of a car radio with all the basic features of a Palm-size PC (except that it doesn’t fit into a shirt pocket). It has a display screen but no keyboard, and it uses sound to communicate with its user. Spoken commands are received and interpreted by a voice recognition system, and output can be provided in the form of a voice synthesizer (and also on the screen).
Windows CE Internet API
Table 1 shows the evolution of
Internet support for various generations of Companion PC devices. The sockets API is a key component of any Internet-aware system, since every Internet interaction is performed using sockets. The WinInet API is an extension to the Win32 API that Microsoft created to support the creation of Internet clients. A set of Win32 system services, the Internet Information Service (IIS) API was created to support the creation of Internet servers. Since Windows CE was built to be a client operating system, it has complete
WinInet support. And since Windows CE is not intended to run on Internet server machines, it has no support for the IIS programming interface (though some third parties provide alternative ways to use Windows CE as a server). The other four items in Table 1 reflect ways to browse the World Wide Web.
Sockets
As this table shows, every Companion PC device supports sockets. This communication API was born in the Unix world as a standard API for
network communications. Regardless of the underlying network transport, sockets provide a standard, stream-oriented way to send and receive network data. This API was a real boon to programmers who were working on network software. It provided a standard API that made the mechanics of network communication similar to that of file I/O. As you may know, a Win32 program reads and writes file data by calling ReadFile and WriteFile. The corresponding socket functions are send and recv, and these same functions
work whether the underlying network is from Novell, Banyan, Microsoft, or another vendor. They also work whether the operating system is Unix, Linux, OS/2, Mac OS, VMS, MVS, or Windows.
Windows Sockets was created by a group of network software developers who wanted the same benefits in Windows that they had in other operating systems. But Windows Sockets were introduced in Windows 3.1, which was built on a non-preemptive, single-threaded scheduler. The problem was that network programming often involves
sending data, then waiting for the reply by making a blocking call. A blocking network call would hang the user-interface on this early version of Windows, so some changes had to be made to sockets to make them work politely in Windows. A new set of nonblocking functions was created that meshed well with Windows’ message-based multitasking. These include functions like WSASend and WSARecv, where the “WSA” stands for “Windows Sockets Asynchronous.”
The support in Windows CE for
sockets corresponds to WinSock 1.1. Since the latest version of WinSock is v. 2.0, some of the enhancements for Windows 95 and Windows NT are not supported in CE. More importantly, Windows CE does not support asynchronous sockets. Windows CE, after all, is a multi-threaded OS, so hanging the operating system is a non-issue. Another reason that asynchronous sockets are not supported on Windows CE is size. As I mentioned earlier, CE was built to be as small as possible. So anywhere the Win32 API has redundant
features, the duplication is eliminated by removing functions.
The lack of support for asynchronous sockets in Windows CE will primarily inconvenience developers who need to port Windows socket code that was written using asynchronous sockets. When you port such code to Windows CE, you’ll have to completely rewrite your sockets handling code to work with the synchronous blocking calls. Such code will also need to use threads, which provide a good way to handle blocking calls without disrupting the
user-interface or other parts of the system.
WinInet
The WinInet API consists of a set of functions to support common Internet operations. As with other parts of the Win32 API, support on CE is a subset of what is available on desktop versions of Windows. In some cases, desktop support has been omitted entirely. For example, the gopher protocol is not supported on CE, and so the associated gopher APIs—GopherOpenFile, GopherSendData—are
not present on Windows CE. With the other part of the Win32 Internet API, support also matches the support on the desktop. For example, all file transfer protocol (FTP) functions are available on CE. And for the remainder of the WinInet library, a select set of functions has been included in Windows CE. The presence of most of WinInet on CE is due in large part to the fact that the WinInet APIs were created for client-side Internet support. And CE was created to be a good network client.
HTML viewer control
The HTML Viewer Control provides basic HTML parsing. Its primary role is to serve as a simple way to implement HTML-based help on CE. The help engine on CE is called peghelp.exe, and it uses the HTML Viewer Control. You summon help by calling CreateProcess to run this program and providing the name of the help file as a program argument.
The HTML Viewer Control parses basic HTML, but it does not display images, run JavaScript, or perform
URL processing for you. When it needs to handle these special cases, it calls back to you and lets you decide what to do. In short, it provides basic HTML viewing capabilities, but it is not a full-blown Web browser. To get that, you’ll want to create a Web browser control, something that is only supported in Windows CE 2.12 and later. And it’s only supported on systems equipped with Internet Explorer for Windows CE.
Pocket Internet Explorer
Microsoft has developed two separate, distinct browsers: Pocket Internet Explorer (PIE) and the Internet Explorer for Windows CE (IE for CE). PIE first became available with Windows CE 1.0. IE for CE started shipping with the Platform Builder for Windows CE 2.12. As of this writing, IE for CE is not shipping in any Windows CE devices, but it is expected in the not-too-distant future.
PIE is roughly equivalent to version 3 of the Internet Explorer. It supports HTML 3.2, which means it supports
basic text attributes (color and fonts) and also tables. But it does not support frames, cascading style sheets, Dynamic HTML (DHTML), or any of the other advanced features that Microsoft provides with IE 4.
The key benefit of PIE is its size. At about a megabyte, it’s the browser of choice when you need more than basic HTML output and you have a tight memory budget. It does quite a bit more than the HTML Viewer Control, and can traverse URLs and display GIFs and JPEG images. While it displays GIFs,
it only displays the first frame of animated GIFs, which arguably makes it less useful for general purpose Web browsing.
Microsoft has been working fast and furious on PIE, and shipped v. 3.0 with Windows CE 2.11. That is the version of CE that ships on the HPC Pro devices (a follow-up to the basic HPC devices). Version 3.0 supports JavaScript, which opens the door to dynamic content. However, PIE supports neither embedded Java applets nor ActiveX controls. If your application requires you to support
those, you’ll need to get IE for CE.
Internet Explorer for Windows CE
IE for CE is a port of Microsoft’s Internet Explorer 4.01 (IE4) browser. As such, it has most of the features of desktop IE4, but not all of them. The features that were cut were ones that did not seem to be widely used, or which have code size requirements that are out of line with the benefits they provide.
Among the included features are support for JavaScript,
ActiveX controls, and embedded Java applets. Of course, support for embedded Java depends on the presence of a Java Virtual Machine to actually run the Java applet.
The HTML support in IE for CE is just about the same as IE4, with just a few exceptions for client-side data binding. Otherwise, the HTML parsing library, MSHTML.DLL, is pretty much the same on CE as it is on the desktop. In particular, there is support for frames and cascading style sheets, neither of which is supported in PIE.
IE for CE
also has support for the Web browser control. This effectively gives you a mechanism for embedding a browser in any application of your choice. Through the associated IWebBrowser2 interface, you can create connections with all of the objects on a Web page and manipulate them to your heart’s content.
Among the features not included is VBScript support. This makes sense given the size requirements of VBScript and the small number of sites that use this feature (vs. JavaScript, which seems to be
winning the Web page scripting wars).
Channel Browser
The Channel Browser is a Windows CE feature that allows content to be downloaded from the Internet to Windows CE devices. It’s an extension of the Active Channel feature of Microsoft’s Internet Explorer 4.0 and later. Microsoft bills this as “push” content on the Internet, by which servers automatically download new content to a user’s system. While Active Channels look
like push content to a user, the delivery vehicle is often an ActiveX control on a user’s machine. These controls automatically connect to the server on a regular basis and download new content.
For push-model sites that support the Channel Browser, specially formatted content gets stored on the user’s desktop PC. When the CE device is connected to the PC, it gets transferred to the CE device. Not all Web content can be downloaded to the Channel Browser, since the smaller screen size and
limited storage space are constraining. Another constraint is the level of HTML support that exists on a CE device (only HTML 3.2 is present on the first generation of Palm-size PCs). Also, not all media types can be played on a CE device, and these must be excluded from web content that gets sent to the Channel Browser. For example, CE doesn’t support the playing of AVI files, and so it doesn’t make sense to download this type of data to a Channel Browser system. On the other hand, GIF and JPEG are
supported, so both of these data types can be downloaded and viewed correctly.
While it’s not a browser, the Channel Browser is built on Internet technologies to support a store-and-forward model of reading web content for users who need access to data on the go. It is perfect for features like news, sports scores, and other data delivery services. It could easily be used to download late-breaking price cuts to a mobile sales force, or to any other population that relies on CE devices for data
collection, order taking, or any of the other tasks for which this family of devices is well suited.
A lite version
Windows CE is nowhere near desktop Windows in terms of overall system capabilities. And its Internet support will never match all that you have on larger, desktop systems. But Microsoft has attempted to provide a capable set of features for CE users to use the Internet to do their work. As Windows CE grows and matures, its Internet
support will no doubt play a central role in making it the system of choice for small, mobile system users who need to stay connected.
Paul Yao is the co-author of five books on Windows programming, including the first book published on the subject. Paul is president of The Paul Yao Company (
www.paulyao.com), which specializes in training software engineers to develop applications for Windows-based technologies. Contact him at
info@paulyao.com.
