.Net's missing links

Improvements to the Compact Framework notwithstanding, Microsoft's mobile strategy is still a game of wait and see

When microsoft rolled out Pocket PC 2002 in September, it dared all of us to expect more from our PDAs and phones than appointments and address books. At the time, it was easy to believe that .Net could become the glue that binds mobile devices to the Internet and server-hosted applications. The field was wide open, and an intriguing beta release of the .Net Compact Framework made it look like widespread Windows mobility was just around the corner.

Before Microsoft could round that corner, the economy tanked, Sun sold Java into major brands of smart phones, Hailstorm succumbed to public mistrust, and the bottom fell out for PDA prices. Java is everywhere, and so far, the .Net Compact Framework lives only on the Pocket PC. That is not a bad thing in itself, but it is a far cry from the expectations that Microsoft created a year ago.

Bits and pieces

The second beta of the .Net Compact Framework comes with Visual Studio .Net 2003, code-named "Everett." Compared with the first Compact Framework beta, very little is new. A couple of interface controls have been added, and the integration with Visual Studio .Net is much cleaner. SQL database access has been tuned up. But the big story with the second beta is performance.

The performance of the previous beta was so poor, even on Pocket PC 2002, that we advised using it only as a proof of concept. Now the framework's performance outpaces the mobile edition of Visual Basic 6. Based on our tests with a Casio Cassiopeia E-200 Pocket PC 2002 device and a prerelease build of Everett, Compact Framework performance is well within acceptable bounds.

Everett's faster, more stable Pocket PC emulator makes application debugging less of a chore. Targeting a physical Pocket PC during development is still a bit tedious. It takes a long time to push the framework and the application code and data files to the handheld, compile it, and set up communication with the debugger. But it's all automatic, and once the application is running, you can set breakpoints, single-step through statements, and change variable values, using Everett's GUI.

Something's missing

When you create a new Compact Framework project in Everett, you must choose between two target platforms: Pocket PC and Windows CE. This illustrates the narrowness of the range of Compact Framework devices and how, so far, .Net's cross-language promise has not been extended to mobile devices.

Microsoft's smart phone is slated for introduction in the first quarter of 2003, yet the device doesn't appear in the form of an emulator or a development target in the version of Everett we tested. We also noticed that even though .Net is designed to host multiple languages on a common run time, the Compact Framework only supports two .Net languages: C# and Visual Basic. Microsoft's other languages have loyal followings and established track records in Internet-enabled applications. Their absence in the mobile space will be felt.

Java catches up

Sun has the advantage of mature specifications and signed deals with leading mobile device manufacturers. When comparing the two platforms' penetration, keep in mind that Java doesn't try to do everything Microsoft has taken on.

Microsoft's mobile software is a complete solution, managing everything from hardware control to the GUI. Even though the .Net Compact Framework presents a more advanced interface to system services than Windows CE's Win32 API, the framework can't be separated from the massive Windows CE. In contrast, the Java Virtual Machine and mobile Java APIs are wired into a device's existing system software by the device maker.

To make the Windows CE porting job easier, Microsoft had to link up with Intel to push down detailed hardware specifications to device manufacturers. By building a device to Microsoft's fairly narrow specifications, device makers bypass most of the pain of porting Windows CE. The result is a device that looks and feels like every other Windows CE device in its class. Consistency can be good or bad for a device. It's good for PDAs because it creates a market for third-party applications. Phone vendors prefer to differentiate their products with proprietary features and interfaces. Integrated mobile devices could go either way, but early efforts by RIM and Danger emphasize uniqueness over uniformity.

Sun simplified the task of Java porting by staying as far away from the hardware as it could. There is no standard specification for a Java phone or a Java PDA; Sun's specs cover programming interfaces. Even there, manufacturers can implement only portions of the Java specification, opting for device-specific interfaces as they see fit. Programmers can't yet expect to port any but the most rudimentary Java programs from one brand of mobile device to another. If device vendors and developers decide that deep cross-device application portability is important, Microsoft's approach will gain traction. The Compact Framework is late to the game and disappointing in some regards, but Java has not yet locked Microsoft out of the mobile market.

Copyright © 2002 IDG Communications, Inc.