I wrote this in November 2004. It remains just as applicable to this day.
I wanted to make a few comments on the state of Palm OS tools and such, and I didn’t want to post them publicly because they’re not exactly positive. If there’s a better place to send them, please let me know. Don’t worry, there’s no questions here… and I don’t mean any of this to be insulting, either, if I’ve phrased some of it that way I apologize…
PalmSource seems to be focusing mostly on “Cobalt.” This is important for the future, I definitely agree with that. But in the near term, there are no Cobalt devices actually shipping and will not be for months yet. How long until the majority of shipping handhelds are Cobalt? I’ll be a bit optimistic — I figure it’s at least two years. Developers in the business of making a profit over the next few years need to focus on Garnet. I have not even looked at the Cobalt tools yet, and have no intention of doing so for many months yet.
The current state of affairs for Palm OS Garnet development is rather poor. PalmSource seems to be putting the majority of their efforts into the Palm OS Developer Suite. I am starting a new Palm OS product, and am no longer actively involved in maintaining the first one (which is on the market and being maintained by someone else; if you’re curious, see www.principalm.com). So it was the perfect time to switch to the new tools. I downloaded PODS and gave it a try, but I ran into a few problems.
The first is that the IDE is pretty unfamiliar. And this is from someone who has used a dozen or more IDEs over the years. I couldn’t even find a way to “quick open” SDK header files within the IDE. Making a makefile was easy (and, to be honest, I prefer this approach to an IDE) but getting the files recognized by the workspace was a pain. I’m not exactly sure how anyone uses a SCM with it; just the limitation of storing everything in Program Files is huge, and I never found a way around that one.
But finally I had everything in the workspace and compiling. Here’s where the real problems began — I had to segment. Segmentation is a fact of life under Garnet, and the documentation for segmentation is very weak — did I say weak? Between myself and a co-worker (working on yet a third product, with no code in common with either of the first one or mine), we couldn’t find anything on it as part of the install. I had some ideas how to do it for C, but none at all for C++. He figured out how to segment eventually and emailed me on it…
Now, which segments were too big? The error messages were next to useless for figuring it out. Still, through trial and error I reduced the size of my segments. That’s when I started running into data segment size issues. What was wrong? Well, I still have no clue at all.
So one night after about a week of fighting it, I threw threw in the towel and moved back to Codewarrior Palm (the latest Mac version). I sent an email to my coworker: “I gave up on PODS. It struck me last night that even if I got everything compiling in PODS, there was no real advantage over Codewarrior that was likely to matter to me for a while. [With Codewarrior, I] had my project compiling within ten minutes. No segmentation issues at all. Hopefully by the time I start to run up against the limitations in Codewarrior Palm’s tools will be ready, because they’re not right now…”
I expected him to tell me to keep fighting PODS, but apparently he’d done the same thing the vary same day, only he moved to the latest Windows version: “I came to same conclusion late last night and am now doing my demo work in CodeWarrior.”
So I just put in an order for the latest version of Metrowerks’ Windows-hosted tools. Will they save me? I don’t know. I’m worried — the new version of Codewarrior is based on the PRC tools,. So am I probably going to be fighting it for data segment size. (I know the standard RTTI/exceptions off trick. I need exceptions. I’m trying to write 21st century C++ here, not 1988-era ANSI C….)
As an aside, this is wrong — Codewarrior Palm 8’s linker is not based on PRC-Tools. This is why I ended up settling on Codewarrior as my development tool.
My conclusions:
1. There has to be a greater focus on Garnet development. Cobalt is the future (maybe.. if it’s late enough, the future is probably going to be the dreaded PocketPC), but it isn’t going to keep me or anyone else in business now.
2. There has to be a lot more work done on both documentation and tools for Garnet. The current (PRC-based?) toolchain — in particular, the linker — needs a lot of work and is under-documented.
3. All of these segmentation issues I’m dealing with are “artificial,” in that segments don’t actually hold any meaning other than legacy to the current Palm OS. If there was a way to write an application for Palm OS 5 that wasn’t PACE/68k, this whole series of problems wouldn’t exist. But still, there’s a couple years to wait until I can stop worrying about this mess.
Anyway, I hope none of this insulted you. Not my intent at all. And I could very well be wrong, I just call it like I see it.
We’re almost in 2006. What’s changed since then? NOTHING. Cobalt still doesn’t exist in any tangible way, and there’s still been no significant efforts put into the Garnet toolchain.
(Also, I want to add: For the one guy out there who recognizes this email, I do not blame the lack of progress on you. I dug up this particular email only because I felt it was the best one I’d written on the subject.)