> So far, the engineering group has opted to not set the format of file
> streams in stone, so that it could be switched to a different
> implementation later on. For example, if the HotSync manager was changed
> to support memory blocks > 64k, then simpler and more efficient
> implementations of the API would be easy to do.
for example, the code that works on Palm III, IIIx and V (my code)
does not work on the emulator when running on the OS 3.5 color
device rom :)
for those people that are dependant on the format, can it at least
be documented for each OS version? using a FileStream is one of
the easiest mechanisms right now for getting data into the device.
would it be more reliable (as a developer) to take the existing
FileStream source code, modify it towards our needs and provide
a library for it? (which will work on all versions)?
just a thought? :)
> If your desire is to simply hack the current format, without caring about
> future compatibility, looking at FileStreamPrv.h even in the 3.0 SDK should
> give you the info you need. (And Aaron, one problem is that your code
> assumed that the length indicator was two bytes, preceded by two zero
> bytes, and you were reporting problems with >64k of data, so... if you look
> at the header you'll see that the file length is a 4 byte quantity!)
david, by definition, the largest block is 4096 bytes. :) this
will fit into 2 bytes :)
here is some code from the FileStreamPrv.h header file:
---
#define fileDataBlockSize (1024L*4) // 4096
#define fileDataBlockSignature ('DBLK') // signature
typedef struct FileBlockHeaderType {
DWord sig; // is assigned to fileDataBlockSignature
SDWord dataSize; // the size of the data in the block
} FileBlockHeaderType;
typedef struct FileDataBlockType {
FileBlockHeaderType hdr;
Byte data[fileDataBlockSize];
} FileDataBlockType;
---
although the "dataSize" variable is a 32 bit integer, it only
represents the maximum number of bytes that exist in a single
block (which is right now, MAX 4096) - unless the header
information is incorrect? here is the exact c+p from the header
---
typedef struct FileBlockHeaderType {
DWord sig; // signature (for debugging and validation): set to
fileDataBlockSignature
SDWord dataSize; // size of valid data in the block (can be less than
fileBlockDataSize)
} FileBlockHeaderType;
---
i believe the problem i am having may with the PDB generator,
which probably cannot handle files greater than 64KB :( i have
the OS source now, so i will rewrite the PDB creator from
scratch - then i will know for sure :)
i was sure the dataSize only used two bytes, as i generated a
stream on the device and then set the backup bit on the DB
and hotsync'd and investigated the format.
every block was 4096 bytes in length (dataSize = 0x00001000) with
the exception of the last record entry, which was the remainder
of the total length divided by 4096 :>
any ideas? :)
cheers.
az.
--
Aaron Ardiri
Lecturer http://www.hig.se/~ardiri/
University-College i G�vle mailto:[EMAIL PROTECTED]
SE 801 76 G�vle SWEDEN
Tel: +46 26 64 87 38 Fax: +46 26 64 87 88
Mob: +46 70 656 1143 A/H: +46 26 10 16 11
