Now hosted on github.com/gdraheim/zziplib

Extras

The next requests circulated around other file-extensions to automagically look inside filetypes that have zip-format too but carry other fileextensions - most famous might be the ".PK3" files of ID's Quake game. There have been a number of these requests and in a lot of cases it dawned to me that those guys may have overlooked the zzip_dir_open functions to travel through documents of zipformat under any name - that is that the "magic" was not actually needed but they just wanted to read files in zipformat with the zziplib.

Other requests circulated around encryption but I did reject those bluntly, always. Instead there have been always examples for doing some obfuscation around the zip-format so that the stock zip/unzip tools do not recognize them but a game software developer can pack/unpack his AI scripts and bitmaps into such a zipformat-like file.

After some dead-end patches (being shipped along with the zziplib as configure-time compile-options - greetings to Lutz Sammer and Andreas Schiffler), the general approach of _ext_io came up, and finally implemented (greetings go to Mike Nordell). The _open()-calls do now each have a cousin of _open_ext_io() with two/three additional arguments being a set of extensions to loop through our magic testing, a callback-handler plugin-table for obfuscation-means, and (often) a bit-mask for extra-options - this bitmask even has "PREFERZIP" and "ONLYZIP" options to skip the real-file test magic in those zzip_*open functions.

Oh, and note that the mode,ext,io extras are memorized in the respecitive ZZIP_DIR handle attached, so each of the other calls like zzip_file_open() and zzip_read() will be using them. There are a few helper routines to help setup a new io-plugin where the init_io will currently just memcopy the default_io entries into the user-supplied plugin-struct.

And last some stdio-like replacements were build but these happen to be actually just small wrappers around the other posix-like magic-calls. It just offers some convenience since wrappers like "SDL_rwops" tend to use a stringised open-mode - and I took the occasion to fold the zzip-bits for the _ext_io-calls right in there recognized via special extensions to the openmode-string of zzip_fopen().

For some reason, people did need the full set of function-calls() to be working on zzip-wrappers too, so here they are - if the ZZIP_FILE instance did wrap a real file, then the real posix-call will be used, otherwise it is simulated on the compressed stream with a zip-contained file - especially seek() can be a slow operation: if the new point is later then just read out more bytes till we hit that position but if it is an earlier point then rewind to the beginning of the compressed data and start reading/decompression until the position is met.

And last not least, there are few informative functions to use function-calls to read parts of the opaque structures of zzip-objects and their zzip-factory.