PhysFS Updates and roadmap.

[Ryan C. Gordon]

I've patched platform/win32.c to compile again. This is what I get for
making updates to a source file without any way to compile it.  :)

platform/unix.c should now be usable for Darwin-based systems, thanks to
Patrick Stein.

I'd like to slowly start moving towards a 1.0 release of PhysicsFS, so
here's a brief list of stuff I'd like to accomplish. This list is subject
to change/addition, but I figure we should probably rip up the internals
now instead of later. I don't have any plans to change the public API,
though, so it's safe to develop with PhysicsFS now, even though the
library behind-the-scenes will twist around a little. There will be some
minor API additions (read on...).

Here's my brief list:

- Switch the CHANGELOG to list newest changes first.

- Write manpages, preferrably generated from some javadoc-style solution
so we can make HTML versions etc from the same data.

- Add typedefs for specific integer sizes (PHYSFS_uint32, PHYSFS_sint16, etc).
We can probably jack this from SDL, but we shouldn't make PhysicsFS
reliant on SDL, so it'll be a cut-and-paste deal.

- Make internal code respect these typedefs.

- Byte order API; just something simple like:
    __EXPORT__ PHYSFS_uint16 PHYSFS_swapBE16(PHYSFS_uint16 val);
    __EXPORT__ PHYSFS_uint16 PHYSFS_swapLE16(PHYSFS_uint16 val);

   (these can be macros. The hard part is determining the architecture at
    compile time, and whether a given platform offers accelerated
    conversion macros already. We can probably jack this from SDL, too.)

- Make win32.c respect the more strict filesystem layout enforced by
Win2000 and later.

- Improve ZIP_seek() (archivers/zip.c)

- entry_is_symlink() and version_does_symlinks() in zip.c have byte-order bugs.

- Actually, the zipfile driver could use a lot of tweaking. Please look
through it.

- Abstract out the use of stdio. It's not as "std" as I would like, in my
experience. Add code to the platform drivers to open, read, write, seek,
tell, etc on an abstract data type that is opaque outside the individual
platform drivers, so that dir.c has a unified codebase that talks to this
internal abstraction layer. This opaque data type can be a FILE * on unix,
and a HANDLE on win32, etc...

- Other archivers: perhaps tar(.gz|.bz2), RPM, etc. These are less
important, since streaming archives aren't of much value to games (which
is why zipfiles are king: random access), but it could have uses for, say,
an installer/updater. I thought it might be neat to have MBOX and Maildir
support so that both "archives" look identical to an application; might be
nice for an email program. That's blue sky, unless someone wants to tackle
it.

- Add autoconf support?

- Look for FIXMEs (many marked with "!!!" in comments).

- Port to BeOS (might work already? Will work for sure with autoconf support)

- Port to MacOS Classic (needs a platform driver, byte order fixes mentioned)

- Port to MacOS X (specifically, make Project Builder files; unix.c should
work with it as-is. Might compile as-is with the current Makefile, byte
ordering fixes mentioned).

- Probably other stuff. Requests and recommendations are welcome.


If anyone wants to jump in and tackle any of this, let me know. I will not
be working on this for quite awhile, but that list is what I would like to
see for a 1.0 release. There may be a physfs-0.1.5 release before we hit
the final 1.0, too, depending on how this progresses.

Alright, everyone. Get hacking.

--ryan.