The next version of the Pocket PC software has arrived and brought with it some attractive enhancements. Having used the new Pocket PC 2002, I can tell you that all the changes are welcome improvements. But the release of Pocket PC 2002 means that things have become somewhat more complicated for the Pocket PC developer.

The first thing I need to do is explain some syntactical definitions. "Pocket PC 2002" is not an operating system ­ it is shell software that runs on top of the Windows CE 3.0 operating system. Pocket PC 2002 (codenamed Merlin) is the next version of the Pocket PC specification. The first was the "Pocket PC 2000" (codenamed Rapier).

Pocket PC 2000 has been around since April of 2000. Many developers created applications for the Pocket PC 2000, and that mandated that Microsoft make the Pocket PC 2002 specification as backwardly compatible as possible ­ good news for many developers.

To develop applications for the newest Pocket PC using the eMbedded Visual Tools suite, you will need the Pocket PC 2002 SDK. At the time I wrote this article the 2002 SDK was not available. I contacted Microsoft and was assured that the new SDK, due for release in late October 2001, will support eMbedded Visual Basic (eVB) as well as eMbedded Visual C (eVC++). The new SDK does not add much functionality to eVB. However, a number of exciting new APIs (Application Programming Interface) are added to eVC, and we need to discuss these. First though, let's look at one of the most important changes to the Pocket PC 2002 specification, one that impacts developers considerably. It is that the Pocket PC 2002 ONLY supports ARM based Pocket PCs.

Pocket PC 2002 only supports StrongARM processors

For developers moving forward, this means that if their legacy applications are required to run on non-ARM based platforms; targeting, for example, organizations with a significant investment in SH3 or MIPS devices; they will probably continue to develop to the Pocket PC 2000 specification. For the most part (ARM) applications compiled for Pocket PC 2000 will continue to function on Pocket PC 2002. So given that most Pocket PC 2000 ARM applications will run on Pocket PC 2002, what would be a compelling reason to develop against Pocket PC 2002? Well, since only the StrongARM processor is supported, developing for Pocket PC 2002 will dramatically reduce the testing for multiple platforms. Additionally, the Pocket PC 2002 has some new features which may meet critical application needs. For example, some applications will benefit from utilizing the new Inbox message store, or the unique device ID capability. However, existing applications that use the City List or use APIs to access the Inbox message store will need to be modified to run on Pocket PC 2002, since these features have been modified.

Enhancements of interest to developers

There are several Pocket PC 2002 enhancements that developers should be aware of. First is the fact that the user interface has changed. The most noticeable change being the lack of the File menu in all applications on the device, as well as the addition of the "tap and hold" animation to provide immediate feedback on the target of the tap.

The Pocket PC 2002 specification also calls for all devices to host a 128 bit "universally unique" DeviceID. This DeviceID is unique for all Pocket PC devices regardless of manufacture. Aside from the obvious use of this feature for Digital Rights Management, developers will embrace this feature as a way to combat software piracy as well as enforce data integrity issues when it comes to sharing information between devices.

A number of the new APIs have been introduced to manipulate the features of the new interface such as the new notification "bubbles" (popup message bars). It would be tempting for developers to use these in their applications (it was my first thought!) but after some contemplation you will realize that the triggers for these notifications should remain within the jurisdiction of e-mail origination programs and SMS or instant messaging applications. There are not that many instances when an application should use the new notification dialog boxes instead of application level message dialogs.