Dr. Dobb's Journal July 1998
Al is a DDJ contributing editor. He can be contacted at astevens@ddj.com.Last month, I described my first foray into Windows CE programming. I talked about the usability and performance of the first generation handheld PC (HPC) devices. I also rued the limited ability of this platform to support real-time applications. Since writing that column, I attended the Windows CE Developer's Conference. This conference is in its fourth year and is hosted by Microsoft. Attendees are typically C and C++ programmers who are or want to be developing programs to run on Windows CE devices. The new SDK also supports CE application development with Visual Basic.
Microsoft now identifies three specific platforms for Windows CE devices, each with its own unique programming considerations.
The Windows CE SDK plug-in to Visual C++ supports all these platforms.
If you are a big fan of Windows CE, you might not like what I have to say. In my considered opinion, Windows CE in its current incarnation isn't there yet. Its three platforms, cute and endearing as they are, fall short of adequately supporting their respective targeted users for different reasons, which I'll address later. Its development environment -- the Windows CE SDK running under Windows NT 4.0 -- is buggy, fragile, and temperamental, as you too will be after trying to install it.
Those opinions notwithstanding, you are likely to find gainful employment as a C++ programmer who knows the Windows CE development environment because Microsoft is in full promotional hyperspeed and, if the growing attendance at this conference is any indication, product managers and their developers are listening.
HPCs have an allure, to be sure. The other day, I was looking at a display of handheld devices at Computer City. A fellow standing next to me was slathering over a first generation Casiopeia A-11, now reduced to half its original price. I told him I have one and hate it and said why. He pointed to a PalmPilot and said he couldn't understand why anyone would want one of those little devices. I answered that PalmPilot has about a million happy users. He ignored all that valuable witness, turned his attention back to the A-11, and with a glazed stare wondered out loud if his company would buy him one. Logic cannot penetrate the protective shields of an enamored consumer about to part with plastic.
All the vendors who exhibited at the conference displayed new HPCs with Windows CE 2.0. Each new machine sports a slightly bigger keyboard than the first generation, and several have well-lit color displays. Those with monochrome displays, even with their backlighting, continue to be unreadable in all but the brightest of lighting conditions. Only two vendors, NEC and Hitachi, have keyboards that I would consider using to touch-type. These machines are pricey but have some potential for road warriors. They are not pocket rockets, being just a bit smaller than the smallest notebook computers. They use proprietary battery packs, which sacrifices the convenience of flashlight batteries and adds a charger, power cord, and maybe a second battery pack to what you have to lug around. They are companions; you still need a desktop connection. In other words, new generation HPCs have few of the advantages of the original HPCs, or of conventional notebooks, and most the disadvantages of both. The form factors are growing, but the technology has yet to reach maturity.
During the conference, we learned that 3Com, purveyors of the very popular PalmPilot product line, had sued Microsoft in Europe for trademark infringement over the use of the name "Palm PC." We then heard that 3Com had prevailed in that action, forcing Microsoft to find a different name for the line, which several manufacturers have already begun to produce. Microsoft did not comment on this judgment, but, without enough time to change its slide shows, continued to use the name "Palm PC" to represent those products throughout the conference. After the conference, we learned that the new Microsoft moniker would henceforth be "Palm-size PC."
Several booths allowed attendees to try out Palm-size PC devices. My first reaction: Microsoft doesn't get it. The PalmPilot is popular because it is simple and easy for users and programmers. PalmPilots do not have multitasking, Control Panels, Registries, drivers, and exotic Setup programs to confound programmers and confuse users. Palm-size PC devices, on the other hand, have all that. They are narrow Windows CE devices without keyboards. The Windows UI paradigm, complex enough on desktops and marginal at best on HPCs, doesn't port well at all to the smaller Palm-size PC form factor. (That's twice. "Form factor" is a new buzz-phrase to add to your technocabulary. Every pitch at the conference was liberally sprinkled with form factors.)
My reaction to the Palm-size PC? All conference attendees were promised one to be mailed in a month or two when the little boxes are in full production. I'll reserve final judgment until I get mine (assuming that lowly members of the press qualify for the freebie; I'm sure not going to buy one). At first glance, the product line looks like a knee jerk reaction to someone (3Com) who is making a lot of money selling a computing device that Microsoft does not control.
The second Windows CE platform is the Auto PC, which is a device to be installed in the dashboard of a car. It is voice actuated and presumably can send and receive e-mail, trade stocks, and do other urgent tasks that cannot wait until you get where you are going. It also reports on your car's status -- something that gauges and idiot lights apparently no longer do well enough -- and connects to a GPS so you don't get lost on your way to the local cyber cafe. There were three luxury cars parked on the conference tradeshow floor. Attendees could climb in and try out the Auto PCs while spectators viewed the devices on video monitors. Every time I went to look at one, somebody was sitting in the driver's seat, yelling at the device, trying to get it to do something. I overheard a young programmer express his enthusiasm about the Auto PC after climbing out of the Jaguar convertible. "What a cool device! I've got to have one! As soon as they are available, I'm getting one, for sure!" Then, after a pause he added, "I guess I'll have to get a car, too."
The voice-recognition Auto PC opens a whole new arena for road rage. Instead of flipping the bird or shooting out someone's tires, you can pull up next to their convertible and yell at their Auto PC, "Buy 10,000 shares of Borland!" or "Forward all personal e-mail to wife!"
I give Auto PCs the same chance for universal acceptance that pen computing enjoyed a few years ago. Maybe Generation X or whoever follows them into the 21st century will find compelling uses for this new technology while it waits for some important problem to solve. Remember CB radio? I'm hanging on to my road maps and watching the mechanical fuel gauge at least for a while. This skepticism kept me from going to any of the Auto PC technical sessions, so I have nothing more to report. I just don't see any future in it.
Microsoft is positioning Windows CE as an embedded operating-system platform. The company presents this position as if it was the plan all along, but I smell revisionism. Every session that addressed the Embedded Developer's Kit (EDK), or embedded development in general, paid lip service to real time requirements. It grudgingly acknowledges that Windows CE, which uses the Windows operating model for sending notification messages to applications in response to events, is not a real-time operating system. Windows CE ISRs cannot be nested; an event cannot interrupt an interrupt service routine. They suggest that a program should signal a thread from its ISR and exit the ISR as soon as possible to permit other interrupts to be sensed and processed. The mechanics of a thread receiving a signal involves the Windows messaging system, which sends a notification message to a window whenever the heck it feels like it. Windows CE 2.0, the current version, does not correct this problem; neither does 2.1, soon to be released. Microsoft expressed its commitment to solving the real-time issue with interrupt and ISR latencies of 50 and 100 microseconds in a future version; they seemed surprised that a significant majority of the attendees were embedded system programmers.
This apparent real-time support deficiency in Windows CE prompted many offline discussions. At lunch one afternoon, one of the guys polled for a consensus definition of "real time." Those at the table generally agreed that real-time requirements are a function of the application and can be expressed in measurements that range from nanoseconds to fortnights. How fast must a system respond to an external event and what are the consequences if the response is late or lost? Is the user taking an online examination, trading stocks, piloting a spacecraft, or stitching a microscopic suture during bypass surgery? From that consensus we agreed that Windows CE could claim to be a real-time operating system only for applications with real-time requirements that fit within CE's operating envelope.
In other words, you can't define real time outside of the context of some specific real-time requirements. Given that vague definition, a batch payroll system could be called real time if it consistently delivers paychecks to the employees by quitting time on payday. Which is why I reject that definition.
Until Microsoft adds true real-time support, it cannot credibly claim that Windows CE is a serious player in the embedded operating-system market.
During several technical sessions, the presenters pointed out that Visual C++ does not support Standard C++ exception handling (the try/throw/catch idiom) when compiling to a Windows CE target. They made vague references to platform incompatibilities. That reason does not make sense to me. C++ exception handling is a language issue implemented in code. Its implementation has nothing to do with the platform. The compiler emits code into statement blocks that can throw exceptions. That code stores in a table somewhere the addresses of automatic instances of classes that have destructors and the addresses of the destructors. The throw mechanism uses that table to call the destructors as it unwinds the stack. It's just code that occupies memory.
The only valid reason I can see for disabling the feature is because of the added overhead. I surmised that a platform without enough memory to support exception handling isn't going to be able to do much recursion or store and pass any sizable instance variables. In other words, it isn't going to be able to support languages such as C and C++ that use the stack for local variables and function arguments.
I stopped by the Metrowerks booth to look at the CodeWarrior compiler for Windows CE. They told me the same story. No C++ exception handling or RTTI because of platform restrictions. Figuring I'd have a better chance of talking to a compiler builder at Metrowerks, I called the company. It turns out that Metrowerks fully intends to include exception handling support in a future version of its CE C++ compiler. Metrowerks just hadn't done it yet. But it has successfully implemented the feature in the Metrowerks PalmPilot compiler, which has a much smaller (ahem) form factor than the typical CE device.
My latest electronic toy acquisition is the 3Com PalmPilot. I got one because it was on sale, because it actually fits in a shirt pocket, because everyone I know who has one likes it, and because there is a C++ compiler for developing applications. This is one delightful little machine. Its elegance is found in its simplicity. I'll report more when I have the Metrowerks compiler and can build an application.
Last month, I told of my frustrations getting the SDK installed and working in a new NT system. The conference materials included the latest SDK version, one that supports 2.0 and the new platforms.
Since last month, I had learned that Visual C++ and Internet Explorer 4.0 are not compatible on NT 4.0. When both are installed and you run Developer Studio, something happens internally that screws up the Registry irrecoverably. The symptom shows up when you try to log in as other than an administrator. Things stop working and go downhill from there until they reach bottom and NT won't boot. Because of that, I had to reformat the NTFS drive, reinstall NT, and start over again.
I installed VC++ 5.0 and the new CE SDK on my clean NT workstation. Following the instructions, I reinstalled Service Pack 3. Something in this procedure caused NT's Remote Access Server to refuse to start. I removed and reinstalled Remote Access Server. All attempts to access the CE device from this point forward forced NT into an unstable condition in need of a reboot.
Those of you who have had this experience or similar ones are nodding gravely and feeling my pain. Those of you who had no such problems are gnashing your teeth and preparing to fire off e-mail to tell me what an idiot I am. I don't know which group is the majority, but this I do know: Until Microsoft makes this development environment more stable, programmers are going to look elsewhere for a way to write CE programs -- or for better platforms to support.
I do not have a happy ending here. I am overdue on this deadline and the problem remains unsolved while I write. Surely it can be solved, and certainly I will solve it, even if I have to call in my secret weapon (my daughter Sharon) who is a Microsoft Certified Systems Engineer on the NT platforms. I'll let you know.
DDJ