.wsz skins cannot be used on Windows
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 over 4 years ago
- Description updated (diff)
#2 Updated by Carlo Bramini over 4 years 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 about 4 years ago
minizip looks like a good option.
#4 Updated by Hieronymous Anonymous about 4 years ago
Has this bug been fixed?
#5 Updated by Ariadne Conill over 3 years ago
What would URIs look like in a zipfile?
Something like file:///home/ariadne/foo.zip/bar.mp3 ?
#6 Updated by John Lindgren over 3 years ago
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.
#7 Updated by Ariadne Conill over 3 years 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 over 3 years 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);
#9 Updated by Carlo Bramini over 3 years ago
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.
#10 Updated by Ariadne Conill over 3 years ago
I think adding libarchive as a dependency is fine tbh. It's already on most systems and builds fine on Windows.