[physfs] Mounting Archive from within an archive

[Ryan C. Gordon]

> So now I wanted to add archive support. Many missions usually are shipped as 
> ZIP which contains the HOG-files and other info. 
> 
> My idea is to mount such a ZIP to" missions/" and then open the HOG whenever 
> it's needed.

Following up...this now works in revision control. I couldn't sleep one 
night so I decided to rip a bunch of stuff up.

There's a new interface available to apps, PHYSFS_Io, which is a bunch 
of function pointers for read/write/seek, etc. You can fill them in and 
pass it to PHYSFS_mountIo(), which is basically PHYSFS_mount(), but 
instead of a real file, it operates on the PHYSFS_Io.

That's a low-level interface for unusual applications. All the archivers 
now use it behind the scenes, instead of __PHYSFS_platformRead(), 
etc...most applications will never use it; the existing APIs will remain 
and be supported as first-class functions as usual.

There are a few uses of PHYSFS_Io that I suspect will be common enough 
to provide them in PhysicsFS itself, though. They'll use PHYSFS_Io 
behind the scenes so you don't have to.

    PHYSFS_mountMemory(): works like PHYSFS_mount(), but takes a memory 
buffer instead of a file, so you can have an archive that's not backed 
by a real file at all. All i/o will be done only to RAM.

    PHYSFS_mountHandle(): works like PHYSFS_mount(), but takes a 
PHYSFS_File* instead of a file, so you can trivially have an archive in 
an archive.

Both are testable from test_physfs.c. This, for instance...

    mountmem $REAL_FILENAME / 1

...will load $REAL_FILENAME into RAM, close the file, and pass it to 
PHYSFS_mountMemory().

...and this is a bit more complicated...

    echo "testing 1 2 3" >file.txt
    zip -9r inner.zip file.txt
    zip -0 outer.zip inner.zip
    ./test_physfs
    mount outer.zip / 1
    mounthandle inner.zip / 1
    cat file.txt
    quit


The only other immediate use I'd see for PHYSFS_mountIo() would be some 
sort of encryption scheme. archiver_zip.c doesn't know the bytes it is 
reading are encrypted on disk, because the PHYSFS_Io is decrypting them 
as needed. As far as the .zip archiver is concerned, it's just asking 
for more bytes from a PHYSFS_Io like it always does.

The next major step after this is exposing PHYSFS_Archiver, and letting 
apps register their own file formats. PHYSFS_Io handles the transmission 
of data, PHYSFS_Archiver turns that data into some meaningful structure. 
I haven't started on this, but it should be a less traumatic change than 
this was.

Please note that these new APIs are still subject to change, and 
comments on them are welcome.

(If I have another sleepless night, I really need to merge Christopher 
Nelles's patches, though. I haven't forgotten it, honest!)

--ryan.