[physfs] PalmOS support

[David Hedbor]

Having programmed some for PalmOS I thought I'd add my
input. Basically I don't think it's worth it. This is from a PalmOS 4
perspective. I don't know if PalmOS 5 is any different.

- PalmOS doesn't have a path. There is just one flat "directory". 
- There is no need to use an archive file (zip for example) for
  resources - there already are builtin datafiles.
- You don't want to "load" an image, for example. Rather in PalmOS the
  bitmap is actually stored and used from the same memory space
  (actually I shouldn't say that, because I'm not 100% certain - I
  think this is the way it works).

Basically the main reason is that there's no need. Data and images and
such is easily loaded from an archive file using builtin api's.


Brian Hook <hook_l at pyrogon.com> writes:

> Ryan and I have been talking a bit about the ability to support 
> PalmOS.  PalmOs is a notably ugly operating system to program for 
> because of its limited resources -- it uses mem handles that need to 
> be locked, etc.
>
> I'm not a PalmOS developer, but I've read some documentation, and I 
> think that it would be reasonably easy to add basic support to it 
> modulo standard portability weirdness.
>
> The key issue is whether to try to handle loading binary resources 
> within PhysFS or have the application be responsible.  I'm leaning 
> towards the latter, and I've been thinking that this could easily, 
> almost trivially, be accomplished by adding a new entry point like:
>
> PHYSFS_addBitsToSearchPath( const char *name, 
>                             const void *data,
>                             int data_dize,
>                             int format );
>
> It would then work normally, but when searching for a file there would 
> be a preloaded image in addition to disk images that it could search.
>
> This way the app is responsible for loading, allocating and locking 
> the data resource, but can otherwise rely on PHYSFS to handle archive 
> read/write.
>
> The major downside to this is that you have a locked chunk of memory 
> at all times, which may not be feasible.  I'm not sure if a clean API 
> for handling lockable resources would be worth the trouble though.
>

-- 
Eon Games - The Games Mobile Penguins Play 

Sales: 	sales at eongames.com    Support:  support at eongames.com
Bugs:   bugs at eongames.com     General:  info at eongames.com

Website address: http://eongames.com/