Audacious - OLD, PLEASE USE GITHUB DISCUSSIONS/ISSUES

It is possible to handle directly ZIP files on Windows with some API, but in my opionion, since Audacious is already released with zLib, perhaps it would be worth to just import the small unzip.c and unzip.h from zlib sources, into contrib/minizip:

https://github.com/madler/zlib/tree/master/contrib/minizip

and free all platforms from the dependency to an external tool.
In this way, the skins will be loaded directly in memory from the ZIP file, without the need to unpack them on disk, like you said.

Sincerely.

minizip looks like a good option.

Has this bug been fixed?

What would URIs look like in a zipfile?

Something like file:///home/ariadne/foo.zip/bar.mp3 ?

I was thinking of something along the lines of:

VFSFile foo ("file:///home/ariadne/foo.zip", "r");
ZipReader reader (foo);
VFSFile bar = reader.open ("bar.mp3");

And ZipReader would provide its own VFSImpl functions (e.g. fread/fseek/etc.) that would wrap the minizip functions.

But I haven't worked it out in detail.

Well, the reason I ask is because some module sets are distributed as archives.

So, I think instead of using minizip, it makes more sense to just use libarchive and have a VFS plugin to do it. I just am not quite sure how the API should be, perhaps we need to extend VFS API to handle containers of files somehow.

My suggestion right now would be to abstract VFS API to add directory tools, where we can iterate over contents and also fopenat(3) using the "directory" handle as the reference. In stdio this means you use a DIR, in the theoretical libarchive adapter, it would be whatever libarchive uses.

I've no problem with supported other types of archives as well.

Maybe we could start with an ArchiveReader class providing something like:

ArchiveReader (VFSFile && archive_file);
Index<String> read_folder (const char * path);
VFSFile open (const char * path, const char * mode);

Libarchive provides many types of archives, for both reading and writing.
If I can say my opinion, it seems a bit exagerated for reading .wsz files which are known to be just ZIP archives.
In that case, you will be forced to set libarchive as a required dependency, otherwise the player will loose the ability to access to compressed skins if it is absent.
Perhaps you may consider to support libarchive as an option and allow to decompress .wsz with minizip.
Afterall, if you consider the size in bytes of unzip.c/h, it does not seem a big problem to me.

I think adding libarchive as a dependency is fine tbh. It's already on most systems and builds fine on Windows.