opment environments are well on their way to incorporating the visual development features found in desktop packages like Visual Basic.
Tough Crowd
In this roundup, we explore development packages for five families of hand-held systems. We say "families" because the ranks of hand-held systems are growing daily as manufacturers extend and add product lines. Furthermore, some of the packages we review serve multiple hardware targets; for example, you can use the Windows CE software development kit (SDK) from Microsoft to develop for the Casio Cassiopeia, the Compaq PC Companion, the Hitachi Handheld PC, the NEC MobilePro HPC, the Philips Velo (see the review "This Hand-Held Stands Out"), and more Windows CE hand-helds as they appear.
Like Microsoft, Geoworks and Metrow
erks are not in the business of manufacturing hand-held hardware. Geoworks purveys its GEOS operating system and development tools -- available on hand-helds such as Hewlett-Packard's OmniGo 100 and 120 and Nokia's 9000 Communicator. Metrowerks, well known for its CodeWarrior compiler, has extended that compiler for developing Palm OS applications for the U.S. Robotics Pilot (see our review, "Multiplatform CodeWarrior," January BYTE, page 47). And Psion not only manufactures its own hand-held systems, such as the Series 3a, 3c, and Workabout, it also offers several development packages for those systems.
Windows CE
is Microsoft's new operating system for hand-held PCs (HPCs). The company has defined a reference platform for a device that fits in your pocket, weighs less than a pound, has a keyboard, is priced under $500, has no-brainer desktop data synchronization, and is easy to learn and use. Win CE, a scaled-down version of 32-bit Windows, is the component that delivers the last
requirement. When you turn on a Win CE device it looks like gray-scale Windows 95 on a small (one-half VGA) LCD screen.
Thanks to its Windows heritage, the CE development environment uses familiar Windows development tools. You need to have Microsoft's Visual C++ 4.0 (not the latest 4.2 version) and the Windows CE SDK, all running on a Windows NT 4.0 system with at least 60 MB of free disk space. The only cabling you need -- for purposes of final debugging -- is the serial cable that's supplied with each HPC.
The Win CE OS uses about half of the 32-bit Windows APIs, plus a few extensions specifically for Windows CE:
- Support for multithreaded, multitasking applications
- Memory-management messages for handling low-memory situations
- A nonvolatile object store that contains registry, program data, and database files
- Command bars: a GUI region at the top of a Windows CE window that contains buttons, combo boxes, menu bars, and other UI items
- RAPI (Remote API): a set of fu
nctions for executing various CE functions, such as registry-access commands, on the HPC, from the desktop
- Notifications: timed events for alerting users and for timed program-to-program communication
Win CE also uses a few extensions specific to CE. The two most unique parts of the architecture are the object store and command bars. The registry (similar to the Win 95 registry), executable programs, and standard stream-oriented data files are all stored in the object store. Programmers can also use a database, a set of records where each record is a collection of one or more properties of type signed or unsigned integer, string, 64-bit date/time values, or a binary large object (BLOB).
Command bars are the primary
UI feature
separating Windows CE from Windows 95. Because screen real estate is precious, Microsoft mandates that you can have only one set of primary UI controls at the top of an application's single window. You manage these controls just as you do other
Windows controls: by intercepting and responding to messages in your main event loop.
Creating and debugging Win CE code is virtually identical to creating desktop code. You build a project, add source code files and resources, select a target, and compile. You can target the MIPS R4000, Hitachi SH3, and x86 desktop emulator. If you select the MIPS or SH targets, the integrated development environment (IDE) attempts to download the executable to an HPC connected to the serial port. If you choose the emulator, it transfers the executable to the emulator's object store and launches the emulator.
At the time of this writing, the Windows CE SDK was in beta, with availability and price yet to be determined.
GEOS is
an operating system designed for a variety of personal devices, from hand-held computers like the Hewlett-Packard OmniGo series to smart phones like the Nokia 9000. Geoworks was one of the first companies to design an object-oriented OS specifically for small dev
ices. The company's early entry into this market is reflected in the maturity and depth of the OS. GEOS is a multithreaded, multitasking architecture that can fit into a small memory footprint. It's a dynamic, OO architecture with a rich set of base classes for UI components, messaging, charting, graphics, and database objects; several types of programmer-controllable virtual memory; and even high-level objects like a spreadsheet.
Setting up a GEOS development environment can be a
bit complicated
. You need a host and a target system, connected by a null modem cable. Geoworks recommends the following:
- Host: A 486 or higher DOS system with at least 8 MB of RAM and 200 MB of free disk space
- Target: Any PC-compatible DOS machine (a 386 is recommended) with at least 10 MB of free disk space
In addition, eventually you need a real device for final testing.
The GEOS SDK is a set of discrete tools -- C preprocessor, linker, make facility, upload and downloa
d utilities, assembler, and symbolic debugger -- that can be used from the DOS command line (there is no IDE). Also included are UI and localization tools that run under GEOS 2.0 for the desktop. You also need Borland's C/C++ compiler, version 3.1 or higher.
Most GEOS applications are written in C using GEOS-specific source file definitions for all program classes and methods and standard C for normal processing modules. One of the major benefits of the GEOS OO architecture is its patented, flexible user interface, where you define UI objects in general terms like their preferred screen orientation and relationship with other UI components. The OS then positions the components based on these hints. You avoid specifying components in pixel terms and get source code that is, theoretically, portable.
After defining your objects, you run them through the preprocessor, then through the Borland compiler (along with your standard C modules), then through the make utility, and then you upload your applica
tion to the target machine for debugging. Although the debugger is quite powerful (you can define your own commands using the TCL scripting language), its interface is archaic and the program is not especially bulletproof.
The
U.S. Robotics Pilot
is the smallest of the hand-helds whose development systems we tested. At 4.7 by 3.2 by 0.7 inches, it fits into your shirt pocket. We did our testing with a Pilot 5000, which is equipped with 512 KB of storage. As with the Magic Link, the Pilot's development platform is the Macintosh-hosted CodeWarrior compiler. However, whereas Magic Cap development software is bundled with the CodeWarrior Gold 11 compiler, you need the separate CodeWarrior Pilot software to develop on the Pilot.
When we received our Pilot and the CodeWarrior software, we were concerned about their lacking a means of downloading applications from the Mac to the Pilot. However, the Pilot comes with a docking cradle, attached serial cable, and HotSync software for th
e PC (an equivalent package will shortly be available for the Mac). Using HotSync not only allows you to update the Pilot's data contents (to-do lists, notepad notes), but it also lets you download new software. Once we had a Pilot application built, we copied it to the PC and used HotSync to install it.
The CodeWarrior Pilot software includes a Pilot simulator. This simulator provides a realistic imitation of a full Pilot hand-held. Once you've got an application ready for testing, you simply compile and execute it in debug mode and the simulator starts up automatically, with your application running. You can use the simulator's various inspection features to watch, for example, the processing of system events as your application executes.
The guts of a Pilot application look much like a typical event-driven Macintosh application written in C. You define an application's visual components using the Mac resource editor, ResEdit (CodeWarrior Pilot arrives with resource extensions that you load into
ResEdit for defining Pilot-specific visual controls). This
is both a
strength and a weakness: If you've done even moderate Macintosh C programming, you'll feel at home in Pilot development; but ResEdit doesn't provide visual development. For example, if you're putting a button in your application, you enter the button's screen coordinates as numeric values. But to see if you got the position right, you have to compile and run the application in the simulator.
Though the debugging side of development on the Pilot is well supported by the simulator, the process cries out for more visual development tools. Let's hope Metrowerks hears those cries.
Though Psion makes a number of hand-held systems, we examined development tools for the
Series 3c
, an NEC V30-based system running at 7.36 MHz, with 2 MB of ROM, a complete (though shrunken) QWERTY keyboard, and no stylus. Our unit also had 2 MB of RAM.
You can choose among three routes to build software for
the Psion, each with its own language and environment. Least demanding is the Organizer Programming Language (OPL). OPL source code looks like BASIC -- the Qbasic bundled with DOS, that is, not Visual Basic. It's easy to master and gives good high-level control of system resources. But as an interpreted language,
it suffers
performancewise.
Psion also offers a C development package propelled by Topspeed's DOS C compiler. All the associated tools are DOS-based, so the host platform's disk and memory requirements are minimal by today's standards. The accompanying debugger's feature set is extensive (it provides source-level debugging and execution tracing, for example), but its user interface is quirky. It's a multiwindowed debugger, but the window controls are unlike any we've seen.
Psion's Object-based Virtual Application Language (OVAL) is a dead-ringer for Visual Basic. Programmers experienced with VB will be able to dive into OVAL's familiar forms-based development enviro
nment without looking twice. Some of the controls available in OVAL are specific to the Psion device. For example, one control allows you to query the status of the battery; another provides access to the Psion's high-speed serial link. Another pair lets you build client/server applications on the Psion machine. The controls provide high-level access to the low-level interprocess communications capabilities of the Psion's built-in operating system.
Whatever development system you choose, you'll need an adapter cable that connects your PC's serial port to the Psion's high-speed serial connector (it runs up to 57 Kbps). This not only lets you transfer programs and data to the Psion but also serves as the means by which the C-based and OVAL development packages' symbolic debuggers control the application being debugged. We got our cable with PsiWin, a software tool that provides an easy means of copying files to and from the Psion hand-held (which is how we downloaded our OPL programs when they were ready
for testing).
Psion (our BYTE Best pick) deserves praise for providing a variety of well-engineered development avenues. Our favorite was, of course, OVAL. In fact, we'd like to see something like OVAL for every hand-held system.
To appreciate software development on
the MessagePad
, you must appreciate NewtonScript. And to appreciate NewtonScript, you must be willing to come to grips with terms like
proto
,
slot
, and
soup
, all of which identify important elements of the NewtonScript language. And if you aim to develop software on the MessagePad, you'll have to deal with
idiosyncrasies
of NewtonScript because NewtonScript shapes the development process.
NewtonScript is an object-oriented OS built atop the concept of a
frame
, which is a data structure that consists of an unordered collection of named
slots
. A slot can hold just about anything: a data value, an array of values, code, or a reference to anoth
er frame. The latter instance allows one frame to point to another frame and is the foundation on which NewtonScript erects inheritance.
Frames within the MessagePad's ROM define the fundamental graphical and nongraphical objects that compose a MessagePad application. These frames are called
protos
, and by subclassing protos and overriding the contents of their slots -- similar to specifying an object's properties -- you build a NewtonScript application.
Fortunately, the Newton Toolkit (NTK) makes this an easier process than it sounds. And as foreign as NewtonScript seems, building an application in the NTK bears a remarkable resemblance to forms-based development of the sort offered by Visual Basic. Development with the NTK is made easier by the integrated debugging tools. Chief among these is the Inspector, which -- aided by an adapter cable that connects the Mac's serial port to the MessagePad's -- gives access to the MessagePad's machinations. The Inspector lets you download and execu
te single NewtonScript routines or entire applications. You can set breakpoints, perform a stack trace, examine a frame's slots on-the-fly, and more. (The NTK comes with an adapter cable that connects the Mac to the serial port on the MessagePad.)
The NTK also contains Book Maker software for building digital "books" called NewtonBooks. Though the Book Maker's aim is to deliver readable material, it also lets you include graphics and live controls in each NewtonBook.
As we were completing this article, Apple was finalizing beta versions of a Windows-based NTK. Check the Apple Web site for pricing and availability.
A Hand Up
The small size and apparent simplicity of hand-held systems belie the complexity of building software for such machines. Fortunately, the development tools are up to the task, thanks mainly to crossover technology from the desktop. Pilot's use of Metrowerks CodeWarrior, GEOS's use of the Borland C/C++ compiler, and Win CE's use of Microsoft VC++ are exc
ellent examples of this.
Even if you have great tools, you should plan on investing some time learning about object-oriented systems. Psion, Apple, and GEOS all have rich, deep OO frameworks that require several weeks of serious daily study. After that, you will still need a few months before you can really build bulletproof, commercial-quality software. There are no shortcuts.
One of the biggest challenges for professional developers is figuring out which platform to build products for. No one product has an installed base of more than about 1 million units; most of them have considerably less. You need to be a bit clairvoyant, work hard until one or more of these platforms has a multimillion-unit installed base, and then hope that you picked a front runner.
Product Information
CodeWarrior Pilot....................$299
(PowerPC or 68040 Mac)
Metrowerks
Austin, TX
Phone: (512) 873-4700
Internet:
http://www.metrowerks.com
Circle 1074 on Inquiry Card.
Hand-Held Development Options
