- Dramatically reduce RAM usage: uses between 8 and 11 kilobytes less static
memory for its internal case-folding tables.
- Actually works now. It would fail unconditionally if a codepoint folded
into multiple codepoints, even if the compared string contained those exact
codepoints.
- Now a public API!
- Removed __PHYSFS_utf8strnicmp(): nothing was using it, it was incorrect
anyhow, and what does 'n' represent when either string might case-fold to
something larger in-flight, anyhow?
With the release of ArcaOS, this is a live platform again.
This code probably doesn't compile yet; I've just given it a first shot at
resolving the changes between the last OS/2-supported revision and now.
This still needs Unicode support added in any case.
To use: mount a .zip file as usual, open a file as usual, but append '$' plus
the password to the end of the path, like so:
PHYSFS_File *f = PHYSFS_openRead("/path/to/my/file.txt$MyPassword");
Note that this is the "traditional" PKWARE crypto, like you might get from
PkZip 2.04g or Info-ZIP. They have more advanced cryptography in the modern
.zip spec, but that's not implemented here. If you've ever tried to unzip
an archive and were prompted for a password, you probably saw the traditional
crypto at work.
Note that this is NOT a secure thing: if you ship an app that contains a
password, someone with a debugger can retrieve it. Note also that this
password could be available to any code registered as a PHYSFS_Archiver, and
that due to how archives combine into a single file tree, the wrong archiver
can get the password, at a minimum causing it to fail because passwords don't
match.
In short: make sure you know what you're doing before you use this!
This lets an application supply its own archivers, where they will work like
any built-in archiver. This allows abstract directory interfaces the same
way that PHYSFS_Io allows stream implementations.
This is a work in progress still. The API is still changing, and will remain
at version 0 until it is finalized (a theoretical future version 1 will be
for when the final public interface changes, not when we evolve the initial
API design).
Instead of trying to deal with a count of objects, just give 'em a stream of
bytes. This is WAY simpler to work with at the implementation level, and
removes confusion about what to do with a partial read.
This will be very useful when we expose the i/o interface to applications.
Ryan C. Gordon
Francesco Bertolaccini