David, Palm Developer Support, and everyone out there...
I've written this to the list because I think you and Palm deserve public
commendation for these kinds of messages...
This is the type of information that makes developing for Palm such a pleasure.
In my real life I (mostly) write device drivers and systems-level software;
primarily for Windows. (Lately it's been two projects using WinCE as an
embedded OS - but that's a separate rant... trust me... bringing up a WinCE
platform is its own kind of hell... I must've done something *real* bad in a
past life... Btw, it's not a retail WinCE machine, so not competition for Palm,
and Palm wouldn't be the right choice for either of these devices... [neither
is WinCE!] but I digress...)
I've spent years dealing with Microsoft and their support - even their
*expensive* "Premier support" (approx $30k/year support option), and never
gotten the service and support that Palm provides with this forum, David, Jim,
Keith, and all the other Developer Support folks.
I tend to get put on odd-ball projects - the "we don't know if this is possible,
but it's what we want to do" kind of things... doing the impossible with the
undocumented... so I spend a lot of my time reverse-engineering what's going on
in the bowels of Windows. Rarely has a call to Microsoft yielded useful
information - and even Microsoft's Premier Support was useful less than half
the time.
Highly frustrating, and not very satisfying "technical support"....
To this I contrast the message (below) that David posted - cheerfully explaining
why something is not documented publicly, but still providing the information to
allow Aaron to do what he needs!
Recognizing that developers need to do the currently-impossible, and assisting
us in doing so, is why I enjoy Palm development so much!
Thank you, David, and thank you Palm, for providing this support!
- Al
On Wed, 17 Nov 1999 11:34:20 -0800, you wrote:
>>I noticed the .PDB, .PRC and .PQA formats are now public (or getting
>>there). What about the format for file streams?
>
>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.
>
>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 Fedor
>Palm Developer Support
>
>
>
>
--
-- Alan Weiner -- [EMAIL PROTECTED] -- http://www.ajw.com
