There are some differences in the Windows CE implementation of WinInet. First, most WinInet APIs are handled synchronously. Only InternetReadFile and InternetQueryDataAvailable support both synchronous and asynchronous modes. Second, Windows CE supports Unicode by default. Last, before using any Internet functions, an application must call InternetOpen to obtain a handle that points to an Internet or Gateway object. This handle will be passed to other functions that offer specific Internet services such as issuing an HTTP request.
Under Windows CE, WinInet is limited to client applications using HTTP and FTP. Gopher, cookies, and persistent URL cache functions are not presently supported. While the FTP APIs are available as a Windows CE component, no Handheld PC currently shipping supports them.
The WNet API under Windows CE also contains some caveats. Only the Microsoft network provider is supported, which means, for example, you cannot connect to Novell share drives. Also, the redirector was left out of Windows CE 2.0 for the Handheld PC, and this cripples its ability to use any of the WNet functions successfully. However, Microsoft has now made the missing files available for download from their Web site.
Next are the Remote Access Client and Winsock (along with IrSock). Because Winsock and IrSock are the focus of this article, I will discuss those in greater detail later. The Remote Access Service (RAS) is a software-based multi-protocol router used to connect Windows CE devices to a remote host. Windows CE only provides support for RAS clients. Most of the Win32 RAS functions are present, except those that deal with the server side of RAS. The only other restriction is that RAS supports only one point-to-point connection at any given time, but the connection can be either a direct serial connection or a dial-up connection.
It is important to note that some networking APIs are not supported under Windows CE. None of the LAN Man API calls are supported, and named pipes and mailslots are not implemented. For further information on WinInet, WNet, and RAS capabilities and limitations under Windows CE, consult the Platform SDK documentation.

Windows socket support under Windows CE is a subset of the Winsock 1.1 specification. All of the standard Winsock functions are available except for the asynchronous calls (including the majority of the WSAxxx functions). Some added features include support for Secure Socket Layer (SSL) 2.0, SSL 3.0, and PCT 1.0 security protocols. There is also a set of ICMP support functions used for making "ping" requests.
Winsock support has been extended to handle the IrDA protocol. This extension is known as IrSock, and brings exciting new capabilities to mobile devices. Applications using IrSock are very similar to straight Winsock applications except that the addressing scheme is new. The new addressing scheme was necessary because of the nature of mobile computing. Handheld PCs frequently move in and out of range of various resources, so a dynamic name resolution scheme was required. I will discuss IrSock addressing in further detail later on.

Handheld PCs running Windows CE are designed to communicate with other machines. This is perhaps its greatest strength. As discussed earlier, there are several ways to get a Handheld PC connected to other PCs. The first (and most common) method is to connect to a desktop via the serial cable or the infrared serial port. If you have the Windows CE Services installed, a relationship is created between the Handheld PC and PC. These services, however, are not required to use a serial connection. All that is needed is a desktop with the RAS server installed.
When connecting a Handheld PC to a desktop there are certain limitations. First of all, a connected Handheld PC is not registered with a WINS server unless the redirector components are used. This means that any attempt to resolve the name of the Handheld PC will fail. Second, the Handheld PC is assigned an IP address, but in most cases this address is a local address that is known only to the desktop. This makes it impossible for outside machines to connect to the Handheld PC, but the RAS server will forward the network packets from the Handheld PC to the correct location. Of course, this scenario assumes the typical RAS server setup. It is possible to configure RAS to hand out real IP addresses and configure routing so that the Handheld PC can receive network traffic, but that is beyond the scope of this article.
A Handheld PC is capable of using an Ethernet card, in which case it could be assigned a real IP address (statically or via DHCP). This would allow a Handheld PC full access to reach and be reached by other machines.

Because the asynchronous Winsock functions are not available, developers must restructure their applications to use regular blocking and nonblocking sockets. Programmers who grew up with Windows sockets might have some trouble thinking of sockets without the window messages and event notifications enabled by WSAAsynchSelect and WSAEventSelect, respectively. I came from a BSD socket background, but I have to admit that the asynchronous Winsock model is rather elegant. It greatly simplifies socket programming when receiving data asynchronously. In this section, I will describe what you need to watch out for when coding blocking and nonblocking sockets, and I will present strategies for efficiently using these models.
Socket programming must be proactive; that is, the programmer must take into account the many possible actions that could take place at each Winsock call. With asynchronous sockets, reading and writing only take place when their respective events are triggered. This leaves the programmer free to think about how to perform some computation on the data. With synchronous sockets, the programmer must think, "Okay, at this point I need to read 42 bytes, but what happens if the data hasn't arrived yet?" As a result, the programmer needs to develop a well thought out read/write scheme with awareness of the data flow between the application and the remote machine.

Blocking sockets cause concern because any Winsock API call on a blocking socket may do just that—block for some period of time. Most Winsock applications follow a producer-consumer model where the application reads (or writes) a specified number of bytes and performs some computation on that data. The code snippet in Figure 2 illustrates this model.
The problem with this code is that recv may never return if there is no data pending because the statement says to return only after reading bytes from the system's input buffer. Some programmers might be tempted to peek for the necessary number of bytes in the system's buffer by calling ioctlsocket with the FIONREAD option. Peeking for data without actually reading the data (reading the data actually removes it from the system's buffer) is considered bad programming practice and should be avoided at all costs. The overhead associated with peeking is great because there are possibly several system calls just to check the number of bytes available. Then, of course, there is the overhead of making the actual read call that removes the data from the system buffer.
What can be done to avoid this? The idea is to prevent the application from totally freezing due to lack of data (either from network problems or client problems) without continually peeking at the system network buffers. One method is to separate the application into a reading thread and a computation thread that share a common data buffer. Access to this buffer would be protected through the use of a synchronization object such as an event or mutex. The purpose of the read thread is to continually read data from the network and place it in the shared buffer. Once the reading thread has read the minimum amount of data necessary for the computation thread to do its work, it could signal an event which would notify the computation thread to begin. The computation thread would then remove a chunk of data from the buffer and perform whatever calculations are necessary. Figure 3 illustrates this by providing two functions, one responsible for reading network data (ReadThread), and one for performing the computations on the data (ProcessThread).
One drawback to blocking sockets is that it makes life more difficult if the app needs to communicate via more than one connected socket at a time. The scheme shown in Figure 3 could be modified to have one read and data processing thread per connected socket. This adds quite a bit of housekeeping overhead, but it is a feasible solution. The only drawback is that the solution does not scale very well once you start dealing with a large number of sockets.

The alternative to blocking sockets is nonblocking sockets. Nonblocking sockets are a bit more of a challenge to use, but they are every bit as powerful as blocking sockets and offer a few advantages. Figure 4 illustrates how to create a socket and put it into nonblocking mode.
Once a socket is placed into nonblocking mode, Winsock API calls will return immediately. In most cases these calls will fail with the error WSAEWOULDBLOCK, which means that the requested operation did not have time to complete during the call. For example, a call to recv for 20 bytes will return WSAEWOULDBLOCK if there is no data pending in the system's input buffer. Often additional calls to the same API are required until a successful return code is encountered. Figure 5 describes the meaning for various Winsock calls when WSAEWOULDBLOCK is returned.
Because nonblocking calls frequently fail with the WSAEWOULDBLOCK error, it is important to check all return codes and be prepared for failure at any time. Many programmers fall into the pitfalls of continually calling one API call until it returns a success. For example, placing a call to recv in a tight loop to read 200 bytes of data is no better that polling a blocking socket with the MSG_PEEK flag. To avoid this, the select API can be used to detect whether there is data to be read or whether a socket can be written to. This API call will block until the conditions the programmer specifies are met. The function prototype for select is as follows:

 int WINSOCKAPI select(int nfds,
                       fd_set *readfds,
                       fd_set *write_fds,
                       fd_set *except_fds,
                       const struct timeval
                       *timeout);

 struct sockaddr_irda {
     u_short     irdaAddressFamily;
     u_char      irdaDeviceID[4];
     char        irdaServiceName[25];
 };

 typedef struct _IRDA_DEVICE_INFO
 {
     u_char    irdaDeviceID[4];
     char      irdaDeviceName[22];
     u_cahr    Reserved[2];
 } IRDA_DEVICE_INFO, *PIRDA_DEVICE_INFO, FAR *LPIRDA_DEVICE_INFO;

 typedef struct _DEVICELIST
 {
     ULONG            numDevice;
     IRDA_DEVICE_INFO    Device[1];
 } DEVICELIST, *PDEVICELIST, FAR *LPDEVICELIST;

 typedef struct _IAS_QUERY
 {
     u_char  irdaDeviceID[4];
     char    irdaClassName[61];
     char    irdaAttribName[61];
     u_short irdaAttribType;
     union
     {
         int irdaAttribInt;
         struct
         {
             int     Len;
             u_char  OctetSeq[1];
             u_char  Reserved[3];
         } irdaAttribOctetSeq;
         struct
         {
             int     Len;
             u_char  CharSet;
             u_char  UsrStr[1];
             u_char  Reserved[2];
         } irdaAttribUsrStr;
     } irdaAttribute;
 } IAS_QUERY, *PIAS_QUERY, FAR *LPIAS_QUERY;