(Except for the lzma archiver, since it needs a bunch of external code.)
The difference in binary size, for Linux/amd64 compiled for size (-Os),
is 4 kilobytes. It's senseless to not just compile them all in.
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!
When targeting MinGW-w64's x86_64 target, unsigned long is 4 bytes but void* is
8 bytes. This mismatch triggers the pointer-to-int-cast warning.
(This patch was originally David Yip's work, with uintptr_t instead of size_t).
Under gcc 5.3.0, the presence of these functions and variables generate unused
function / unused variable warnings, which in combination with -Werror causes
a compile error.
We now use a hashtable for lookups of specific paths, and organize the
entries into a directory tree. The end result is fast lookup and fast
enumeration without having to search a sorted array or tapdance with
substrings...which means the rare, mysterious bug where we failed
to find an existing file should be gone now, too.