WinSock Support in Windows CE 2.0

Table of Contents:

Introduction (and Disclaimer)

Windows CE SDK

WinSock APIs

ICMP (Raw Socket) Support

IrSock Functions

Registry Entries

Ethernet Support

Other Notes

Windows CE Resources on the Web

References

Introduction

Windows CE is Microsoft's newest Windows platform, targetted for the embedded systems market. Initially, this market consists mostly of handheld and palmtop pen-based computers (formerly known as PDAs, "personal digital assistants"). But as indicated by their AutoPC design and plans to put CE into set-top boxes and WebTV, Microsoft obviously recognizes that there's a much larger potential for this (relatively) diminutive cousin to Win3.1, 95 and NT, et al.

The communications/networking capabilities are what make CE devices much more powerful than the sum of their (small) parts, and Windows Sockets is a key component for enabling network applications, along with PPP-support and remote dialing capabilities. Data synchronization is the most significant use of the handhelds and palmtops. Hardware configurations vary, but serial and infrared ports are common. Some have a built-in modem or a PCMCIA slot. There are a number of companies with CE-compatible PCMCIA modems available, and there's at least one company (Socket Communications, Inc) that has a PCMCIA Ethernet card (CE 2.0 is supposed to be compatible with any NE2000-compatible PCMCIA card, but that's the only one blessed by Microsoft so far).. And, lest we forget the mobile nature of these machines, there are also wireless interface cards under development for messaging (one and two-way paging), and streams (e.g. using CDPD modems).

Some believe that Residential Networks are going to be one of the Next Big Things. These home networks will be populated by not only PCs that share resources, including a broadband Internet connection (via a cable modem, ADSL, digital satellite, or whatever), but also embedded devices. These may be hand helds and palm tops, but could also be appliances like televisions, stereos, heating systems, alarm systems, video cameras, digital cameras, alarm clocks, automobile, cell phone, and who knows what all else. The possibilities are indeed mind-boggling. "IP over everything" will no doubt be a key enabler, and Windows CE might also.

The best feature of CE is that it provides support for Win32 APIs, MFC (with ATL), and WinSock. Granted, these APIs are only subsets of the Real Thing and there are many portability issues related to disk space, power usage, user interface and peripheral devices (to name a few), but the tremendous number of existing Windows applications represents a potential gold mine. Windows CE is behind the curve in many respects in comparison to other embedded operating systems (e.g. VxWorks, PSoS, OS9, etc.), and although Windows applications tend to be relatively resource intensive, portability represents a significant advantage. Microsoft enhances this advantage with an add-on development environment ntegrates nicely with MSVC++ version 5 (on NT4 or later), and includes the mini-MFC version, and a few samples. It has cross compilers for both MIPS and SH3, an emulator for simulated execution, remote debugging, and it downloads the (release or debug version) to the connected CE device as part of the build process. Microsoft also has CE Dev Kits for Visual Basic and Java (but I haven't tried them).

So, in summary, the purpose of this new addition to the Sockets web site is to explore the possibilities and limitations of the WinSock API implementation on Windows CE. Only time will tell where it goes from here. One thing is for sure, it is here to stay.

WARNING: This page is very much UNDER CONSTRUCTION as I have tested relatively little at this point, and have made quite a few questionable statements that I intend to investigate(marked by "??? need to check"). I also have some place holders that are more for my own benefit than yours (marked by ??? need more info here). Bottom line is that this page is in rough shape as yet... but hey, it's a start!

Please send comments, corrections, contributions or requests. Tell me what you'd like to see here! Thanks in advance - Bob Quinn

Windows CE SDK

Microsoft has a number of Software Development Kits (SDKs) for Windows CE that support C, C++, Visual Basic, and Java. I use the C/C++ version, which is an add-on for Enterprise or Professional editions of Microsoft Visual C++ version 5.0 (but not with the Learning Edition). Although explicitly designed to run on NT version 4 or later, according to Craig Peacock's FAQ the MSVC 5 CE SDK can be used on Windows 95 with some limitations (e.g., the emulator and remote tools don't function properly). Actually, now even the Microsoft literature says you can use the SDK on Windows 95 (and warns the emulator doesn't work).

I've had very good experience with the CE SDK so far. I like the emulator and the fact the build process downloads the executable to a connected HPC. I'd be happier if I could get it to work with the Ethernet interface on my handheld, but as long as I can use the Ethernet interface while connected to the SDK machine via that serial interface, I'm happy. One tool I haven't figured out how to get running is the remote process monitor (I don't know what the client piece is, or what DLLs it needs). That would be nice.

For more information about the CE SDKs, see the Microsoft Windows CE developer website.

WinSock APIs

NOTE: Most of the information on the WinSock API was garnered from the documentation in the Windows CE SDK for Microsoft Visual C++ version 5.0, and also available online from http://premium.microsoft.com/msdn/library/sdkdoc/wince/wceover_5y2c.htm (you may need to subscribe to access this "premium" information, but fortunately Microsoft does not charge for access). Microsoft has also added Windows CE references to the online WinSock API documentation at http://premium.microsoft.com/msdn/library/sdkdoc/pdnds/sock2/wslegal_0twy.htm (interestingly, some of the references conflict, as noted below).

The TCP/IP and IrDA protocol stacks are available in WinSock on Windows CE (both versions 1.0 and 2.0 of Windows CE support these, but this page is version 2.0 specific).

*Protocol Suite*	*Family*	*Structure*	*Protocol(s)*	*Type(s)*
TCP/IP	AF_INET	SOCKADDR_IN	TCP and UDP	SOCK_STREAM, SOCK_DGRAM (no SOCK_RAW)
IrDA (Infrared)	AF_IRDA	SOCKADDR_IRDA u_short irdaAddressFamily; u_char irdaDeviceID [4]; char irdaServiceName [25];	TCP only	SOCK_STREAM

Windows CE supports a subset of the WinSock 1.1 API, as listed in the table below. Notice that most of these are Berkeley Sockets compatible APIs, and four are WinSock-native (WSA) functions. The other missing WinSock 1.1 functions are:

The asynchronous functions (all APIs with the WSAAsync prefix, like WSAAsyncSelect() and WSAAsynchGetHostByName(), etc.)
Service name "database" APIs like getservbyname() and getservbyport (SERVICES Berkeley-compatible "database" file also missing)
Protocol name "database" APIs like getprotobyname() and getprotobynumber (PROTOCOL Berkeley-compatible "database" file also missing)
Blocking-hook related APIs (e.g. WSAIsBlocking(), etc., which are also removed from WinSock 2 implementations).

Interestingly, WinSock on Windows CE also has a single WinSock 2 API--WSAIoctl()--which supports the Secure Sockets Layer (SSL) protocol versions 2.0 and 3.0, and the Private Communication Technology (PCT) version 1 security protocol (for a complete list of the protocols, crypto algorithms, et al, registry entries). This is useful for SSL-enabling any TCP-based application, not just http (secure web).

Here's a list of the WinSock functions available on Windows CE from the 32-bit WINSOCK.DLL. These are compatible with the 32-bit APIs from Win95 and NT WSOCK32.DLL (unlike 95 or NT, CE does not provide any 16-bit application support).

*Function*	*Differences from standard WinSock*
accept() *	none.
bind() *	none.
closesocket() *	none.
connect() *	If no active serial, IrDA or Ethernet connections, connect() with a TCP (SOCK_STREAM) socket fails with 10065 (WSAEHOSTUNREACH)
gethostbyaddr()	Without a local BSD Sockets-compatible HOSTS file, CE WinSock relies entirely on DNS or WINS for name resolution (notice that sockets-compatible SERVICES and PROTOCOL files are also missing, as are their respective APIs). HOWEVER, the registry HKLM\Comm\Tcpip\Hosts\<hostname> keys act as an equivalent to entries in a HOSTS file if the ExpireTime key is removed, so the other keys (ipaddr and aliases) persist. NOTE: This returns ANSI strings in hostent structure which require conversion to UNICODE
gethostbyname()	Without a local BSD Sockets-compatible HOSTS file, CE WinSock relies entirely on DNS or WINS for name resolution (notice that sockets-compatible SERVICES and PROTOCOL files are also missing, as are their respective APIs).HOWEVER, the registry HKLM\Comm\Tcpip\Hosts\<hostname> keys act as an equivalent to entries in a HOSTS file if the ExpireTime key is removed, so the other keys (ipaddr and aliases) persist. NOTE: This returns ANSI strings in hostent structure which require conversion to UNICODE When resolving the local hostname (as returned by gethostname()): 127.0.0.1 address returned if no serial, IrDA, or Ethernet connections are active. 192.168.5.xxx (where "xxx" may vary but is often 101) address returned when serial or IrDA connections active over PPP to a local RAS Dialup Server host. Notice that this is a private address space as defined by RFC 1918, so this address requires translation to access other Internet hosts. Any valid Internet or Intranet address if connected via a modem over PPP or an Ethernet card It is possible to reference *ppp_peer* as the remote hostname to get the address of the host machine when connected via the serial cable. NOTE: This tidbit came from Andrew Tucker who has an article in the April or May issue of Windows Developer Journal (http://www.wdj.com) in which he uses this trick to implement a simple text transfer application.
gethostname()	Host name returned is the CE system name (as found in registry key: HKLM\Ident\Name) NOTE: This returns an ANSI string which requires conversion to UNICODE)
getpeername()	none.
getsockname() *	With IrSock: IRLMP_IAS_GET: IRLMP_ENUMDEVICES:
getsockopt()	Options Supported: (need to check ???) SOL_SOCKET, SO_RCVBUF: on both UDP & TCP sockets, this call caused a GPF for me (not sure why yet)
htonl()	none.
htons()	none.
inet_addr()	none NOTE: Input IP Address string must be ANSI, not UNICODE.
inet_ntoa()	none NOTE: This returns an ANSI string which requires conversion to UNICODE for display.
ioctlsocket()	For SSL support: optname - SO_SECURE optval - SO_SEC_SSL OpCodes Supported: (need to check ???)
listen() *	none.
ntohl()	none.
ntohs()	none.
recv() *	MSG_PEEK flag removes data from the incoming buffer (which it should not do). NOTE: This bug report came from a reliable source, but I have yet to test it.
recvfrom()	MSG_PEEK flag removes data from the incoming buffer (which it should not do).. NOTE: This bug report came from a reliable source, but I have yet to test it.
select()	none.
send() *	none.
sendto()	With a SOCK_DGRAM (UDP) socket: sendto() a multicast address (e.g. 234.5.6.7) before calling bind() doesn't fail, but nothing is sent sendto() same multicast address after calling bind() fails with 10049 (WSAEADDRNOTAVAIL) sendto() (normal unicast address) succeeded even when destination was unavailable (i.e. when no active serial, IrDA, or Ethernet connections). *Memory Leak in WinCE 2.0 with UDP sockets*. See Article ID: Q183364.
setsockopt() *	With IrSock: IRLMP_IAS_SET: IRLMP_IRLPT_MODE: IRLMP_RAW_MODE: Options Supported: (still others to check) SOL_SOCKET, SO_RCVTIMEO: works on both TCP & UDP (SOCK_STREAM & SOCK_DGRAM) sockets SOL_SOCKET, SO_RCVBUF: fail with 10045 (WSAEOPNOTSUPP) on both UDP & TCP sockets unless socket is connected prior to call IPPROTO_IP, IP_ADD_MEMBERSHIP: fails with 10022 (WSAEINVAL). The 10022 error value makes me question my test application's validity, but I've doubled checked and could not find any problem in the code. Lack of support for this socket option means no multicast support in CE2, which is indeed unfortunate! Also see sendto() function description in this table for other multicast problems. IPPROTO_IP, IP_MULTICAST_TTL: does not fail (but sendto() fails anyway, as noted above) IPPROTO_IP, IP_MULTICAST_LOOP: fails with 10042 (WSAENOPROTOOPT)
shutdown()	none. Works as advertised in CE2 (how=1 sends TCP <FIN>), NOTE: An experienced source warned that shutdown(how=1) hangs in CE1.
socket()	none. Requests for raw ICMP sockets--type=SOCK_RAW--fail with 10047, WSAEAFFNOSUPPORT.
WSACleanup() *	none.
WSAGetLastError()	none Same 10000 WinSock error bias, (e.g. 10060 for WSAETIMEDOUT)
WSAIoctl()	For SSL Support: SO_SSL_GET_CAPABILITIES: SO_SSL_GET_FLAGS: SO_SSL_SET_FLAGS: SO_SSL_GET_PROTOCOLS: SO_SSL_SET_PROTOCOLS: SO_SSL_SET_VALIDATE_CERT_HOOK: SO_SSL_PERFORM_HANDSHAKE:
WSASetLastError()	none. NOTE: The CE SDK docs say this works, and my testing indicates it does, but the online WinSock API docs say that this function isn't not supported in Windows CE.
WSAStartup()	WSAData contents upon return after version 1.1 requested: wVersion: 1.1 wHighVersion: 1.1 szDescription: <null> szSystemStatus: <null> iMaxSockets: 10 iMaxUdpDg: 0 NOTE: When I requested version 2.2 it happily accepted it and told me wVersion: 2.2, wHighVersion: 2.2

* These APIs represent the subset available with an IrDA socket (see below for more information). Also note that WSAStartup(), WSACleanup(), WSAGetLastError() and WSASetLastError() are all also relevant to applications using IrSock. They aren't hightlighted in the table simply because they don't reference AF_IRDA socket handles explicitly.

** Although the Windows Sockets 2 Protocol Specific Annex includes a specification for SSL support using WSAIoctl(), these APIs are different than those. Note also, that SSL is also available via the "SChannel" ActiveX APIs.

Microsoft WinSock Extensions

ReadFile() ...??? not a good idea, but will it work with a socket handle ??? need to check
WriteFile() ...??? not a good idea, but will it work with a socket handle ??? need to check
NOTE: NT functions TransmitFile() and RecvFile() are not available.

Other Comm APIs

The focus of this webpage is WinSock, but in passing I'd like to note the (many) other communications APIs available. Minimizing code size is of paramount importance in CE, so using built-in libraries is sensible whenever possible. Good to know what's available.

Internet APIs:

InternetCanonicalizeUrl()
InternetCloseHandle()
InternetCombineUrl()
InternetConnect()
InternetCrackUrl()
InternetCreateUrl()
InternetFindNextFile()
InternetGetLastResponseInfo()
InternetOpen()
InternetOpenUrl()
InternetQueryDataAvailable()
InternetQueryOption()
InternetReadFile()
InternetSetOption()
InternetSetStatusAvailable()
InternetStatusCallback()
InternetTimeFromSystemTime() - ??? NTP - Need to check ???
InternetTimeToSystemTime()

HTTP APIs:

HttpAddRequestHeaders()
HttpOpenRequest()
HttpQueryInfo()
HttpSendRequest()
InitHTMLControl()

FTP APIs:

FtpCommand()
FtpCreateDirectory()
FtpDeleteFile()
FtpFindFirstFile()
FtpGetCurrentDirectory()
FtpGetFile()
FtpOpenFile()
FtpPutFile()
FtpRemoveDirectory()
FtpRenameFile()
FtpSetCurrentDirectory()

Email APIs (SMTP & POP3 and IMAP4 ??? need to check):

TransportConnect()
TransportCount()
TransportDel()
TransportDisconnect()
...others, and also see Mail APIs (to manage messages locally)

RAS (dialer):

RasDelete
RasDial
RasEnumEntries
...others

Rapi (Remote Access Programming Interface):

PegRapiInit()
PegRapiInitEx()
PegRapiUinit()
RapiFreeBuffer()
PegFindAllDatabases()
...and the (many) other PegXXX remote file, database & registry access functions...

SMB APIs:

WNetAddConnection3()
...and others

Raw Serial APIs (the serdev component):

GetCommMask()
GetCommModemStatus()
GetCommProperties()
GetCommState()
GetCommTimeout()
PurgeComm()
SetCommMask()
SetCommState()
SetupComm()
WaitForCommEvent()
...and others

[Go to top]

ICMP (Raw Socket) Support

The WinCE 2.0 SDK documentation states that ICMP Echo Request/Reply (e.g. "ping") is supported via the Microsoft proprietary APIs (same as available on Win95 and NT in the ICMP.DLL). These are the functions IcmpCreateFile(), IcmpSendEcho(), IcmpCloseHandle(). However, these APIs are not available in WinCE 2.0 implementations shipping at the time of this writing (I have an HP 360LX that does not have either a ping or traceroute utility).

I have heard from a reliable source that the latest Windows CE Embedded Toolkit has an ICMP.LIB (no .DLL needed), but it doesn't come with the 2.0 SDK for Visual C++. Sigh... Life without ping is pangful.

On the brightside, WinCE does at least respond to ping requests from other IP hosts.

[Go to top]

IrSock Functions

With an Infrared Data Association (IRDA) socket, only a subset of WinSock functions are available with some modifications, as noted in the function table above. You will notice that for the most part, the APIs not included deal with addresses, names or datagram sockets.

IRDA sockets don't have hostnames, and their addressing is unique (??? need more info here).

IRDA connections are reliable (??? need more info here).

The IRDA sockets all use the IrDA-compabitible infrared interface built-into the WinCE devices to communicate with printers (e.g. HP LaserJet 6P) and computers similarly equipped with IrDA-compatible interfaces. AF_IRDA sockets can only be used with TCP--socket type SOCK_STREAM--not UDP, although a raw mode is possible (see setsockopt() IRLMP_RAW_MODE ??? need more info here).

[Go to top]

Registry Entries

Windows CE has a Registry that--as on NT and 95--reveal many interesting things about the system, and provide some configurable options not otherwise available. Here's a collection of things that seem interesting (to me). I haven't had the courage to experiment with much yet. I'm sure this isn't terribly useful to many in its current form, but anyway...

HKLM: Abbreviation for "HKEY_LOCAL_MACHINE"

TCP/IP settings

HKLM\Comm\Tcpip\

Hosts\ --> this entry seemed dynamic according to host connected with

remote host name\

ExpireTime - Values: , Data Type: <- Without this key entries will persist, which makes this like a HOSTS file!
aliases - Values: , Data Type:
ipaddr - Values: , Data Type:

Parms\

IpEnableRouter - Values: , Data Type:

Linkage\

Bind - Values: , Data Type:

HKLM\Comm\ppp\

Subnetmask - Values: , Data Type:
IpAddress - Values: , Data Type:
UseZeroBroadcast - Values: , Data Type:
LLInterface - Values: , Data Type:
IpInterfaceCo?? - Values: , Data Type:

HKLM\Comm\NE20001\Parms\Tcpip\

IpAddress - Values: , Data Type:
Subnetmask - Values: , Data Type:
DefaultGateway - Values: , Data Type:
EnableDHCP - Values: , Data Type:
DNS - Values: , Data Type:
WINS - Values: , Data Type:

Infrared Interface

HKLM\Comm\IrDA

Security Protocols and Algorithms

HKLM\Comm\SecurityProviders\SCHANNEL\

CAs - Values: , Data Type:
Ciphers - Values: , Data Type:
Hashes - Values: , Data Type:
KeyExchAlgs - Values: , Data Type:
Protocols - Values: , Data Type:

[Go to top]

Ethernet Support

Windows CE 2.0 provides support for TCP/IP over Ethernet using NE2000-compatible PCMCIA cards. Obviously, they provide much faster network access than a serial or Infrared interface can, and now that I avoid the routing problems I've had with serial and infrared interfaces, the Ethernet card has made testing WinSock applications much easier.

I can successfully synchronize over Ethernet (as described here), although due to my particular configuration I must have a Wins Server configured on my H/PC Ethernet interface and not a DNS Server. My partner machine has Windows 95 and two Ethernet interfaces, the outside of which is the default (with a gateway address assigned). I think this configuration is the crux of the problem in the final analysis. Here're my bug report details:

Here's a picture of the configuration:
                       +--------------+                
                       |   Twister    |                  +---------+
  Internet----Cable----<    Win95     >-----Ethernet-----< Tricord |
              Modem    | H/PC Partner |                  |  H/PC   |
                       +--------------+                  +---------+                             
              24.128.34.101        206.105.153.8      206.105.153.6

TWISTER is the hostname I reference in "Connect to:" when I attempt to
start ActiveSync with Network Connection from Tricord.  WinGate is
running on Twister, and configured to do proxy DNS.  It is significant
to note that the 24.128.34.101 interface is the default on Twister,
since it has a gateway address assigned.  The 206.105.153.8 interface
does *not* have a gateway address configured.

When I have the Ethernet interface on Tricord configured with a WINS
server and no DNS server, I *AM* able to synchronize the two systems
successfully.

The problem occurs when I have a DNS server configured on the Ethernet
interface on Tricord (and it doesn't matter whether or not a Wins 
Server is configured).  A network trace reveals the following:
1) Tricord sends out a DNS query to 206.105.153.8 for "TWISTER"
2) Twister responds with a successful DNS response with the address
    for TWISTER (a.k.a. twister.cyko.com) as 24.128.34.101
3a) ActiveSync fails immediately with "Communications Error" message 
     box that says WinSock failed with error 10065 if I do not have a 
     gateway configured for the Ethernet device. 
3b) ActiveSync *seems* to connect (it makes the H/PC connection
     sound on Twister and opens the Mobile Devices window, and on
     Tricord it says "Checking for partnership with this computer,
     Please wait...).  But it never proceeds from there.  Shortly
     thereafter, it fails (on Tricord the "Connecting to Desktop" 
     message box says "ActiveSync not responding on the desktop computer."  

    A Network trace in this case reveals that: 
      a) Tricord successfully connects to TCP port 5679 on 24.128.34.101
      b) Then Tricord FAILS its *many* attempts to connect to the TCP port 
          999 on 24.128.34.101, each of which is reset by Twister.

I was able to work-around the problem described here by adding a static entry to the WinCE 2.0 "HOSTS" file equivalent entry to the Registry, which effectively avoided the DNS lookup that was causing confusion.. I added the key /HKLM/Comm/Tcpip/TWISTER and the values ipaddr (DWORD): 0xce699908 and aliases (String): "{twister.cyko.com}"

Ok, now I'm over that hump and I have ActiveSynch working. Next it would be REAL NICE to be able to use the CE SDK (i.e. Visual C++) with the CE machine attached via Ethernet rather than serial, but I realize that is asking too much (at least for now).

PCMCIA Card Installation Tips

The NE2000-compatible drivers must be installed manually. You can find them among the Optional Components on the Windows CE CD-ROM. As described in the installation instructions on the CD-ROM (in ethernet_readme.txt), you need to copy the binaries to the Windows directory on your HPC (ARP.DLL, DHCP.DLL, NDIS.DLL, NE2000.DLL, NETWORK.CPL). Then insert the PCMCIA card (if it prompts for a driver name, use "NE2000"), and finally configure for IP as prompted. In my case, it worked first try!

So far, the only PCMCIA card Microsoft themselves have tested is from Socket Communications, Inc (http://www.socketcom.com), but I have had luck with the NDC 5100 from ND Communications, Inc. (http://www.ndclan.com), others have reported success with others (e.g. Linksys EC2T), there are quite a few other drivers listed in the HPC registry (in HKLM\Drivers\PCMCIA), but Chris De Herrera reported failure with at least one also (e.g. SVEC NE2000).

The problem with unsupported cards like my NDC 5100 and the LinkSys EC2T is that the HPC prompts for a driver name each time you insert the card. It is easy enough to get the card working by entering "NE2000" each time, but it is annoying. I solved it with help from Carlos A. Santiago's tip, which describes how to modify the registry in a HPC to accomodate an unsupported card. It's not online any longer, but what it used to say was (I paraphrase): use a CE Registry Editing Tool (like the remote version in the CE SDK, or the stand-alone from Grundle Software) you should add the device name found in the .INF file for your adapter to HKEY_LOCAL_MACHINE\Drivers\PCMCIA registry hive. For my NDC 5100 PCMCIA card, I added "NDC-Ehternet-0197" with the keynmames and values (all strings): Dll: ndis.dll, Prefix: NDS, Miniport: NE2000

Sidenote: At first I tried all five of the "Device IDs" I found in the .INF file for my card ("NDC-Ethernet-xxxx", where xxxx .was 24A3, 0197, 6BF4, 6669, CB56), but none of them worked. I then tried installing my card in my Win95 laptop, and checked the Device ID value the installation procedure put into the registry (HKLM\Enum\PCMCIA\NDC-Ethernet-0197). I put this key name in HKLM\Drivers\PCMCIA in the registry of my HPC (using the Remote Registry Editor from the Windows CE SDK tools menu) and also assigned the same fields and values as for the NE20001 entry, and it worked (note that the NE2000 key is linked to the NE20001 key )! Now I don't get prompted for a driver name each time I insert the card any more.

[Go to top]

Other Notes

Although Windows CE provides support for a significant subset of the standard Win32 APIs, and even the Micorosoft Foundation Class (MFC), there are a number of unique characteristics one should note about the Windows CE platform. These are WinSock independent, but affect all WinSock applications.

I have had problems routing from dial-up on serial & Ir interfaces on both Win95 & NT. On Win95 I can get out with browser using WinGate on PC as gateway. Without gateway on NT, I get nowhere (and don't see traffic on the net either). My test TCP client does not generate any traffic on net, and I haven't found a way to monitor traffic on the serial lines.
Unlike NT or 95 (or most TCP/IP hosts), CE doesn't have some basic IP network diagnostic tools: a PING facility, NETSTAT command (for display of network statistics and listening ports), or ARP command (for IP to Ethernet address maps ...although the ARP.DLL must have a query API).
Unlike NT and 95, CE is not backward compatible to 16-bit applications (although the WinSock DLL has the 16-bit name, rather than the 32-bit name).
As on NT, UNICODE strings are native on CE
Unlike any other WinSock implementation, WinCE does not have so-called "database files" (e.g. SERVICES, PROTOCOLS or HOSTS files)
Unlike NT or 95, CE does not support the IP Multicast APIs and doesn't even allow sending to a multicast address
Unlike NT or 95, there's only a single user (actually, not even that, but just a single password, and "owner" info, like name, address, and phone number that can be displayed at power-up).
Unlike NT or 95, there's no console (a.k.a. "DOS box"), although there are console emulators available, and it is possible to write window-less applications (and simply use message boxes to display status messages).
Network interfaces consume power, and Windows CE machines are power starved (and have special power-management APIs).
Windows CE machines are memory starved (and have special memory management APIs).
Unlike NT and (to a limited extent) 95, Windows CE doesn't have a Service Control Manager (SCM), so can't install servers as services.

[Go to top]

Windows CE Resources on the Web

http://www.microsoft.com/windowsce - Microsoft's official Windows CE website

http://www.windowsce.com - HPC.net: Windows CE and Handheld Computing Software, News, Links, and More...

http://www.winceonline.com - WindowsCE On-Line: up-to-the-minute CE news, and good links

http://www.jimmy.com/morency/wishpie.html - Christian Morency's Windows CE Application Wish List

http://www.cegate.com - Fred Bouvry and Christian Morency provide "a gateway to WindowsCE," with the goal of sharing developer info!

http://members.aol.com/pdcchrisd/index.htm - Chris D's Pen-Based Computers (comprehensive FAQs, including one on Ethernet!)

http://www.geocities.com/SiliconValley/8005/620zone/620tips.htm - HP 620 tips, but some are relevant to others (e.g. Ethernet tip referenced earlier).

http://www.webring.org/cgi-bin/webring?ring=windowsce&list - Windows CE Web Ring: Lots of links to Windows CE websites

http://www.surerange.com/links.html - Lots of links to Windows CE related websites (and a mail list to notify you of new updates!)

Dev Tools

http://lists.windowsce.com/developers/ - Windows CE developers' mailing list (need to be a subscriber to access the archive)

http://www.ruksun.com - Some helpful developer tools (e.g. TraceTool, TFTP Server, NSLookup/WhoIs/Finger)!

http://www.inet-1.com/~spamman/wince.htm - Registry editor and File Size utility (called SpaceHog)

http://www.applian.com/products/CEInstall/ceinstall.htm - CE Install utility (a commercial product, with source code)

http://www.microsoft.com/windowsce/developer/download/ - Microsoft WinCE Developer Download Site

Source Code

http://www.oohito.com/ - RegEdit, Console, and others. Site is mostly in Japanese, and download files are LZH compressed files.

[Go to top]

References

Shepard, G. and Wingo, Scot, Mini MFC Revealed, Dr Dobb's Journal, October '97

May '98 issue of Microsoft Journal, on newstands April 17 is dedicated to Windows CE

[Go to top]

Updated 11/25/98 (c) Bob Quinn, 1995-1998

[Return to Home]