[wx-dev] wxPalm dev

[Yunhui Fu]

>  Hmm, sorry, but how is this going to help for the objects allocated with
> operator new?
For my point of view, it should to redefine the new/delete, or even
memcpy/memcmp/strdup...
About the method to archive it, we may refer to some memory debug lib.
There are many of such implementation. I have been read one when I
studied c++ seven years ago. :-)

>
> YF> >  Thanks! If you already have a draft of the new API, could you plea=
se post
> YF> > it here?
> YF> See the patch:
> YF> https://sourceforge.net/tracker/?func=3Ddetail&atid=3D309863&aid=3D18=
58847&group_id=3D9863
>
>  I did look at it but unfortunately it's not easy to understand what is it
> doing just like this. It looks like it introduces some kind of intermedia=
te

PFLib is Palmos' File Lib. :-)

There are three types of file API of PalmOS:

1. PalmOS' PDB API (RAM):
DmFindDatabase()
DmOpenDatabase()
DmCloseDatabase()
DmGetRecord()
DmDeleteRecord()
....
It's only handle the structured PDB files. As the emergence need of
the multimedia device, such as the camera, the PDB is not suitable for
the multimedia data. So the PalmOS invented the steam API:

2. PalmOS' stream file API (RAM):
FileOpen()
FileClose()
FileRead()
FileWrite()
FileSeek()
...
It's looks like the standard file API(open, close, read, write...).
But It's only work with the files in RAM.

3. PalmOS' VFS API (Extend Card): for read/write files in extend card.
VFSFileOpen()
VFSFileRead()
VFSFileClose()
...

These three types of file handle API have different types of parameter
for handling. Such as for opening a stream files in RAM:
UInt16 cardNo=3D0;
Char *nameP=3D"Sms db";
FileHand fh;
fh =3D FileOpen (cardNo, nameP, 'DATA', 'SmsM', cardNo, fileModeReadWrite, =
NULL);

while the files in extend card:
UInt16 volRefNum=3D2; // this value should be get from VFSVolumeEnumerate()
FileRef fileRefP;
Err errNumber;
errNumber =3D VFSFileOpen (volRefNum, "/PALM/data/1.dat", vfsModeWrite, &fi=
leRef);

This two functions have the similar function but have incompatible paramete=
rs.

So I defined the abstract layer(pflib) for hiding those differences.
Please refer to the diagram "palm_vfs.png". The red boxes in the
diagram are the File APIs of PalmOS. The green boxes are the abstract
layer I defined. The grey box is only for porting the abstract layer
to other platform.

Because the standard io, such as open(), use the integer as the file
descriptor, we have to store it to a global variable. So I define this
abstract layer.

The standard io and stream file API can implement above pflib. Please
refer to the diagram: "palm_abs.png".

Another reason for the pflib is that I test it initially in a open
source palm app: FileCanddy.

Thanks!
yhfu
-------------- next part --------------
A non-text attachment was scrubbed...
Name: palm_vfs.png
Type: image/png
Size: 23514 bytes
Desc: not available
Url : http://lists.wxwidgets.org/pipermail/wx-dev/attachments/20080103/990d=
c797/palm_vfs.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: palm_abs.png
Type: image/png
Size: 18919 bytes
Desc: not available
Url : http://lists.wxwidgets.org/pipermail/wx-dev/attachments/20080103/990d=
c797/palm_abs.png