Bug #859

.wsz skins cannot be used on Windows

Added by John Lindgren 11 months ago. Updated 19 days ago.

Target version:
Start date:
January 09, 2019
Due date:
% Done:


Estimated time:
Affects version:


The current scheme uses the external "unzip" program which generally isn't present on Windows.

We could ship an "unzip.exe" along with the Windows build, but it would be better if we could read the .wsz/.zip files directly through the VFS layer, without running an external .exe and creating temporary files on the C: drive.


#1 Updated by John Lindgren 11 months ago

  • Description updated (diff)

#2 Updated by Carlo Bramini 9 months ago

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:

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.


#3 Updated by John Lindgren 9 months ago

minizip looks like a good option.

#4 Updated by Hieronymous Anonymous 7 months ago

Has this bug been fixed?

#5 Updated by Ariadne Conill 20 days ago

What would URIs look like in a zipfile?

Something like file:///home/ariadne/ ?

#6 Updated by John Lindgren 20 days ago

I was thinking of something along the lines of:

VFSFile foo ("file:///home/ariadne/", "r");
ZipReader reader (foo);
VFSFile bar = ("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.

#7 Updated by Ariadne Conill 19 days ago

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.

#8 Updated by John Lindgren 19 days ago

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);

Also available in: Atom PDF