tewha.net

Slashdot is covering the end of CodeWarrior for Mac. Metrowerks has announced that CodeWarrior Pro 10 (a minor update at best) will be the final release of CodeWarrior for Mac. It will not support Intel.

CodeWarrior for Windows is already dead.

No official news on CodeWarrior for Palm out of Metrowerks, but I doubt it will see another update without significant changes within Metrowerks. Metrowerks does not seem to exist anymore, except as a support system for Freescale’s embedded chips.

Palm, having a good tool-chain for Palm OS 5.x is important to the platform. PalmSource is focusing their efforts on Palm OS/Linux, and Metrowerks is completely lacking focus. Thus, it falls to you to provide one if you want the platform to prosper. Make it happen.

(Although unless Palm is stupid, they started this a year ago.)

So I was writing a business layer from scratch for Palm OS 5 (only). It made sense to me to use modern programming techniques and make my objects C++ classes.

I’m now regretting it and rewriting using more basic C. I’ll still use C++, since there’s a lot more to C++ than just classes, but I’m done with classes for data. It really boils down to one reason:

C++ objects are created in the heap. To keep my application’s data around between swaps, the data has to be in storage.

I’ve looked at this from various angles and don’t see any reasonable alternative. I could copy my data from permanent storage (SD, and eventually HTTP) to main storage (data) to C++ objects (heap), but this just adds an extra layer of complexity and a heck of a lot more work to do on suspend/resume.

Instead, I plan to create a “record viewer” class. This class will manipulate the bytes in a data record behind the scenes so the upper application layer doesn’t have to. I can actually keep this fairly efficient, I think, by coding the lower layer carefully.

One thing I’m not sure of is how to handle strings. They’re in UTF8 storage, which I don’t really know much about. I expect I’m going to end up using word length Pascal strings padded to even lengths, which will be faster to step through than C-style strings (I’m also a bit worried about UTF8 possibly having NULL characters, but I could clear up that worry with a quick web search if that was the only reason).

Sometimes the old ways are the best ways.

From Palm Info Center:

In last weeks PalmSource conference call interim CEO Patrick McVeigh also announced the company is shifting all engineering efforts on the future Linux based versions of the Palm OS.

He stated, “We are delaying all development of products not directly related to this.”

He also put a timetable on the release of the upcoming linux Palm OS products. The version for low end and feature phones is planned to be completed by summer 2006 and a high end version for smartphone is expected to be ready in the second half of next year.

PalmSource seemed to almost be floating the “Hey, if you don’t like Cobalt we could put it on Linux” in front of licensees and potential licensees as an experiment. Was anyone interested? Can we get out of our nightmare by doing this? The answer seems to be yes. With luck, the Palm OS on Linux efforts will be more streamlined and less like the nightmare that Cobalt became.

The downside is that it means the very soonest we could see modern Palm OS devices is summer 2006. I wonder if Palm OS will have a new name by then?