Guy Smith
September 1997
The purpose of this article is to present the Microsoft® Windows® CE operating system communications model. Because applications and devices differ in their communications needs, Windows CE supports a diverse collection of communication options and associated application programming interfaces (APIs). Windows CE–based devices can implement any or all of the available options. We will discuss the full scope of communications support for Windows CE–based devices, and how the different pieces fit together in the overall model.
The ability to communicate is a key feature of Windows CE–based devices. It can take a variety of forms ranging from simple serial input (I/O) over a wire to wireless networking with Transport Control Protocol (TCP/IP). In addition to built-in communication hardware, such as a serial cable or infrared (IR) transceiver, PCMCIA support permits a wide variety of after-market communications devices that can added to the basic package.
There are three types of communication supported by Windows CE:
The communications model is represented schematically in Figure 1.
Figure 1. A schematic illustration of the Windows CE communications model
Serial I/O is the most fundamental feature of the Windows CE communications model, and should be available on virtually all devices. At the hardware level, serial communications will usually be accessed via a cable or through the IR transceiver.
A cable connection is handled with the standard Microsoft Win32® API serial and file system functions. They can be used to open, close, and manipulate Component Object Model (COM) ports, and read from and write to them. Overlapped or asynchronous I/O is not supported.
The IR transceiver is assigned a COM port, so direct serial I/O is available using the usual serial communication functions. The I/O will be "raw," which means, for instance, that there will be no collision detection.
More robust serial IR communication utilizing the IRDA protocols is available via IRSock (an extension of WinSock, discussed later). As an alternative to using IRSock directly, IRComm emulates serial communication but uses IRSock and the IRDA protocols internally.
Windows CE has a network stack with a number of different options. It can utilize a variety of hardware, including infrared, serial, Ethernet, and wireless links.
At the top of the network stack, Windows CE supports subsets of the WinINET and Wnet APIs, and a server message block (SMB) redirector.
The WinINET API provides support for Internet browsing protocols, including File Transfer Protocol (FTP) and Hypertext Transfer Protocol (HTTP) 1.0 (Gopher is not supported). Only one proxy is supported, and there is no caching. It also provides access to two Internet security protocols, Secure Sockets Layer (SSL) 2.0 and 3.0, and Private Communication Technology (PCT) 1.0.
The Wnet API provides access to an SMB redirector for remote file access. Currently only Microsoft Windows 95 and Windows NT® operating system connections are supported. The redirector supports Universal Naming Convention (UNC) names (such as //serverXX/shareXX), but not drive letters.
Applications will normally access the network stack via the WinSock interface. Windows CE supports a subset of WinSock 1.0. All standard WinSock functions are implemented, but not asynchronous functions (including most of the WSAxxx functions). Windows CE also supports SSL 2.0, 3.0, and PCT 1.0 security protocols.
IRSock is an extension to WinSock that enables socket-based communication via an infrared transceiver. It is designed to support the industry-standard IRDA protocols. Applications implement IRSock in much the same way as conventional WinSock, although some of the functions are used somewhat differently.
At the same level in the network stack as WinSock, but serving a different purpose, Windows CE supports a Remote Access Server (RAS) client. RAS is a multiprotocol router used to connect remote devices. The Windows CE RAS client is virtually identical to the Win32 implementation, but only supports one point-to-point connection at a time.
The TCP/IP suite was developed for the Internet, and is probably the most flexible and widely implemented network protocol. It is supported by a wide variety of systems and forms the core of the Windows CE network stack.
Many Windows CE–based mobile devices will have wireless communication capabilities. However, conventional TCP/IP stacks, intended to function efficiently on wired networks, may work poorly with wireless technology. The Windows CE TCP/IP stack is designed so that it can be configured to effectively support wireless networking.
For infrared networking, Windows CE provides transport layer support for the IRDA protocols.
At the base of the network stack, Windows CE supports two data-link layers.
Many Windows CE–based devices will connect to their network via a serial communication link, such as a modem. To support this type of networking, Windows CE implements the widely used SLIP and PPP. Authentication is provided via Password Authentication Protocol (PAP), Challenge Authentication Protocol (CHAP), and Microsoft CHAP.
For Local Area Networks (LANs) Windows CE includes an implementation of NDIS 4.0. At present, only Ethernet miniport drivers are supported. Wide Area Networks (WANs) are not supported.
Windows CE includes a Telephony API (TAPI) service provider for Advanced Technology (AT) command-based modems (Unimodem). It can be used with either attached or PCMCIA modems.
TAPI is a collection of utilities that allows applications to take advantage of a wide variety of telephone and communications services without needing detailed knowledge of the particular technology. The Windows CE implementation of TAPI is focused on outgoing calls, and provides outbound dialing and address translation services. Inbound calls are not currently supported. Support for multiple locations is implemented through the Control Panel. To provide flexibility in the choice of hardware, TAPI supports installable service providers.
The Windows CE communications model is designed to function well on a variety of very different types of device. It provides an original equipment manufacturer (OEM) with a diverse set of options to choose from. The modular design permits overhead to be minimized, because only those parts of the model that are required by a particular device need to be included. For further details on adapting the communications model for a particular device, see the Windows CE OEM Adaptation Kit.
For application developers, Windows CE supports most common types of communication. They are accessible via familiar Win32-based APIs, allowing developers to readily implement communications capability in their applications. In many cases, existing code can be used with little or no modification. For more information on writing communications-enabled applications for Windows CE–based devices, see the Windows CE Software Development Kit.