Synchronizing Windows CE

Is ActiveSync 3.0 the full solution?

In "Windows CE Devices," August 1999, I discussed the problems I had synchronizing my various Windows CE devices with my Windows 2000 (Win2K) and Windows NT desktop systems. When I wrote my previous column on Windows CE, I thought Microsoft was turning hard-core users against this OS before it had a chance, thereby killing Windows CE's possibilities.

With ActiveSync 3.0, Microsoft solved Windows CE's synchronization problem with other Windows OSs. Microsoft didn't make much of an announcement about the resolution. (Somehow I missed the release of ActiveSync 1.0 and 2.0.) The original announcement stated that ActiveSync 3.0 supports Windows 9x but didn't mention whether the new software supports other NT flavors. After I drilled down to ActiveSync 3.0's download page, which provided a complete list of features, I learned that the product fully supports Win2K Professional (Win2K Pro) and NT Workstation 4.0.

Before installing the software on my NEC MobilePro 880 Handheld PC (H/PC), I removed Windows CE Services. After I downloaded ActiveSync's 3.2MB self-executing archive file, installing the software was a breeze (especially compared with the rigmarole that installing Windows CE Services required). Next, I ran the installation routine and rebooted the computer, and—voilà—I could communicate with my Windows CE devices. I still couldn't synchronize the Windows CE device with my Microsoft Outlook 2000 calendar, but I could transfer files between the two computers and install applications that required an installation via a host PC. And unlike Windows CE Services, ActiveSync 3.0 has worked every time I've tried to use it with both Win2K and NT desktops.

Users now have an easy-to-use, reliable method to connect Windows CE devices to other computers running Windows OSs. However, Microsoft still needs to deal with two other Windows CE problems. First, Microsoft needs to provide support for Windows CE devices to synchronize with non-Windows OSs. Several years ago at a preview session for Apple Computer's PowerBook, I asked whether the notebook's remote access software included a server-side component that ran on PCs. After engaging in a brief discussion with his associates, an Apple representative asked me, "Why would we want to do that?" The company didn't understand that these notebooks wouldn't compel a PC shop to change to Macintosh servers for remote access. Microsoft needs to deal with this same problem. Users running Mac OS, UNIX, or Linux on their desktops might also use portable devices, and these users will buy the devices that synchronize with their current desktop OSs. And the same users who are playing around with Linux are likely to embrace a good PC companion device.

Second, Microsoft needs to address application development for these devices. Now that H/PCs are gaining wider acceptance and PalmPCs are available with modems, these devices need applications that don't require you to synchronize with your desktop to install them. When I was struggling to get my MobilePro to synchronize with my desktop, I discovered dozens of interesting Windows CE applications. However, I could directly download only a few of the applications, such as shareware FTP and Internet Relay Chat (IRC) clients. Because I needed to synchronize with a desktop, I couldn't install several other applications that looked useful.

If you think I won't need to download applications directly to my MobilePro now that I can easily synchronize with a desktop, you're missing part of the picture. When I travel, I sometimes use my MobilePro to surf the Internet. I often come across interesting Windows CE applications that I can't immediately use because I'm not carrying around a full-blown desktop or a notebook (the applications require a download to a desktop or notebook PC).

Let's think back to the mantra of software and application design: Keep It Simple Software (KISS). Remember that the simpler an application is for people to use (e.g., by supporting downloads directly to a Windows CE device), the more likely people are to use the application. This old principle is often lost in the more-bells-and-whistles mentality that dominates software development.