> I can't think of any way Palm could emulate Big Endian mode successfully,
though:
>
> Palm programs mostly do struct copy stuff like this:
>
> MyStruct shadow, *pRecord;
>
> pRecord = (MyStruct*) MemHandleLock(DmGetRecord(pDB, 1)));
> shadow = *pRecord;
> DmWrite(pRecord, sizeof(MyStruct));
Palm wasn't saying they'd so anything to user structures. They were going
to do some byte swapping of system structures that people are used to poking
inside, things like EventType and WindowType. User data is entirely up to
the user. If you're just running 68K code under emulation, then everything
is big-endian anyway so no problem. If you're running pure ARM code, all
will be little endian. If you need to support both processors with separate
builds of your code, you need to pick one format and have the other
processor swap data before processing.
> And does this imply changes to the PDB format, which has some big endian
unions?
> Man -> Palm Source is IMPORTANT - anyone know if there are summaries of
such things?
I think PDB is considered a wire format now -- while I'd suspect there will
be a NG PDB format, the current structure for PDB exchange is the standard.
On an ARM Palm, it would byte-swap out of whatever backing storage the PDB
was in.
--
Ben Combee
Veriprise Wireless <http://www.veriprise.com>
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
