I don't use the record ID, I only generate PDBs one way  PC->Palm.
All other entries get flipped as well.  Things get a little tricky when
working with floating point but only from the point of flipping the bits and
not altering the value. (plus strings don't get flipped). I've been using
the PDB format doc I got from RoadCoders as my primary guide.  So far it
worked great.  I know Palm frowns on things like this, but its a necessary
evil with the application I'm working on.

[SUGGESTION]-> Palm should officially release the PDB format and support it
within the SDK.  Either by example, dll or library etc...  There seems allot
of interest lately in the PDB format (and PRC).  I would be willing to
donate my C++ Builder code for the cause (provided I can get the company's
OK).

-----Original Message-----
From: Sergio Carvalho <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date: Friday, September 24, 1999 9:49 AM
Subject: Re: Endian problems


>
>I handle creator IDs the same way: 01 02 03 04 becomes 04 03 02 01. Ex:
'data'
>becomes 'atad'. Everything is just like creator IDs, except for the record
>LocalID.
>
>Did you change the records LocalIDs, on your program?
>
>
>Dave Lippincott wrote:
>
>> I don't understand it also, I wrote a PDB access library with creator IDs
>> handled as 01 02 03 04 -> 04 03 02 01 and it works great.  When I open a
PDB
>> I generated in my hex editor, the creator ID is readable.  That is it can
be
>> read left to right within the file. Plus it shows up correctly on the
>> device!.
>>
>> -----Original Message-----
>> From: Sergio Carvalho <[EMAIL PROTECTED]>
>> To: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
>> Date: Friday, September 24, 1999 5:06 AM
>> Subject: Re: Endian problems
>>
>> >
>> >Sorry for the lack of info. I wrote a library to create pdb files on the
>> Wintel
>> >platform. It is usefull to generate dictionaries and stuff that only
needs
>> to get
>> >generated once, where a conduit is an overkill.
>> >
>> >The library was created using VC++, although it doesn't matter.
>> >
>> >A pdb file has this general format
>> >  PDB HEADER
>> >  RECORD 0 HEADER
>> >  RECORD 1 HEADER
>> >  ...
>> >  RECORD N HEADER
>> >  RECORD 0 DATA
>> >  RECORD 1 DATA
>> >  ...
>> >  RECORD N DATA
>> >One of the elements on the record header is the LocalID, which is an
offset
>> to
>> >the beginning of the corresponding record data. My doubt came about when
I
>> >started getting errors on record size which, by comparison with existing
>> pdb
>> >files, I tracked down to the LocalID and its odd swapping of bytes.
>> >
>> >A LocalID, represented on the intel platform as hexadecimal 01 02 03 04,
>> becomes
>> >02 01 04 03 on the palm device.
>> >
>> >My library is working now, using the odd swapping for the LocalID. I
would
>> just
>> >like to understand why...
>> >
>> >[EMAIL PROTECTED] wrote:
>> >
>> >> I have no idea. I have no idea what you're doing or how you're doing
it,
>> what
>> >> platform you're doing it on or what tools you're doing it with.
However,
>> I do
>> >> know that if you have a LocalID with a value of, say 0x01020304, then
in
>> the
>> >> .pdb file, it should appear as 01 02 03 04 if you do a hex dump.
>> >>
>> >> -- Keith
>> >>
>> >> Sergio Carvalho <[EMAIL PROTECTED]> on 09/24/99 01:28:47 AM
>> >>
>> >> Please respond to [EMAIL PROTECTED]
>> >>
>> >> Sent by:  Sergio Carvalho <[EMAIL PROTECTED]>
>> >>
>> >> To:   [EMAIL PROTECTED]
>> >> cc:    (Keith Rollin/HQ/3Com)
>> >> Subject:  Re: Endian problems
>> >>
>> >> Could it be that the LocalID is in fact a pair of Words, not a DWord
as
>> >> indicated in the DataPrv header?
>> >>
>> >> [EMAIL PROTECTED] wrote:
>> >>
>> >> > In general,
>> >> >
>> >> >     01 02 03 04
>> >> >
>> >> > should be converted to:
>> >> >
>> >> >     04 03 02 01
>> >> >
>> >> > I'm not sure what problems you're experiencing with the LocalID.
>> >>
>> >> >
>> >> >
>> >> > -- Keith Rollin
>> >> >
>> >> > Sergio Carvalho <[EMAIL PROTECTED]> on 09/24/99 01:00:41 AM
>> >> >
>> >> > Please respond to [EMAIL PROTECTED]
>> >> >
>> >> > Sent by:  Sergio Carvalho <[EMAIL PROTECTED]>
>> >> >
>> >> > To:   [EMAIL PROTECTED]
>> >> > cc:    (Keith Rollin/HQ/3Com)
>> >> > Subject:  Endian problems
>> >> >
>> >> > How should double words be swapped, when converting from
little-endian
>> >> > to big-endian? A DWord:
>> >> >     01 02 03 04
>> >> > should become:
>> >> >     04 03 02 01
>> >> > or should it become:
>> >> >     02 01 04 03
>> >> >
>> >> > I expected it to be the first case. But when building a pdb, I had
to
>> >> > use the second case to convert the record localID. the LocalID type
is
>> >> > typedefed onto a DWord on the DataMgrPrv.h header. To confuse me
more,
>> >> > the creatorID and database type fall onto the first case. A DB type
of
>> >> > 'data' must be swapped to 'atad'...
>> >> >
>> >> > I feel lost.
>> >> >
>> >> > --
>> >> > Sergio Carvalho
>> >> > ---------------
>> >> > [EMAIL PROTECTED]
>> >> >
>> >> > If at first you don't succeed, skydiving is not for you
>> >>
>> >> --
>> >> Sergio Carvalho
>> >> ---------------
>> >> [EMAIL PROTECTED]
>> >>
>> >> If at first you don't succeed, skydiving is not for you
>> >
>> >--
>> >Sergio Carvalho
>> >---------------
>> >[EMAIL PROTECTED]
>> >
>> >If at first you don't succeed, skydiving is not for you
>> >
>> >
>
>--
>Sergio Carvalho
>---------------
>[EMAIL PROTECTED]
>
>If at first you don't succeed, skydiving is not for you
>
>
>


Reply via email to