'Why?'
Because I need and use it.
'What?'
The full, C-only code for zip archive operations of all sorts, entirely standalone and free of autotools and the like, ready for my intended use directly from Ada code and easily extendable for any other specific use from either C or Ada. It produces and uses standard zip archives. It comes with all needed headers, bells and whistles, a minimal .gpr file for compilation with GNAT as a static library and some commented out examples, too. The heaviest part of it is, unsurprisingly, the code for zip operations that weighs in at 10130 lines in miniz.h. The rest of the code adds about 2400 lines more in total.
To expand a tiny bit on the above, I'm using this exact code as part of the fully automated graphics pipeline that generates on demand any and all graphics that Eulora2 needs, as it needs it. I haven't bothered to "clean" the code to any specific extent beyond the very functional - it either serves or at least stays out of my way. As such, I think the code as it is currently makes, if anything, a good place to start for someone wanting to learn to read effectively code, perhaps - it's reasonably big without being too big and otherwise written and packed at all points by people focused on their own needs for it, not on ticking something off some check lists or using up some time at work.
I'm publishing the code as a 1st edition of MiniZipLib, in VaMP format, of course, since it can be perhaps useful to others if/when they want to avoid depending on external code for any zip-related needs.
Note also that the client for Eulora2 relies currently on something else, essentially external zip code even if this external dependency happens indirectly, via CrystalSpace. This is because all graphics assets are stored and used as .zip files that group together the various parts and pieces that are required at times to make a full model or item. While my current main interest and use for this lib is mainly serverside, the client could certainly benefit as well from reducing its dependency on external code and integrating this. Currently I don't have the time to do it though as the further development of the game itself takes precedence but I'm making the VaMP tree for it public via this 1st edition, so that others can pick it up if they need it.
As usual, feel free to ask relevant questions in the comments, below. If you don't know and need to find out where the code is thus published, it's likely though that you are still missing an earlier step, namely interacting with people so read perhaps a bit more around and see what pulls you in so that there is some better starting point for it all than mere code ever was or ever will be.
Comments feed: RSS 2.0
Did you come across AdaZip from Gautier in the search? I haven't looked closely but it popped up some time ago as possibly interesting (iirc I'd been bemoaning that it seemed all the available decompressors were in C).
That's "Zip-Ada", rather.
I came across Gautier's Ada code before, including the zip lib indeed but sadly there's very little that I could ever use from there. His code relies deeply and heavily on exactly the sort of things I exclude explicitly and on the latest version of everything and so on (even before hitting on the finalization and streams and the like, his ziplib won't even compile with the gnat version I have as it complains about "undefined attribute create_missing_dirs").
At some point I have actually looked through ~all his published code as it was quite a significant set of projects in Ada but in each and every part of it, as my past notes remind me now, I met exactly the same approach and thus the same fundamental mismatch with him, as I describe above. So out of all that dive, the only tiny bit I could use at all was the starter for the .ini file read/write, which appears currently in some adapted form in the client, too, but that's really all of it and not for lack of awareness, quite the opposite.
Since I got curious about the size anyway, I took his latest version now again and checked: the line count for the strictly "zip_lib" part of his code in there (so excluding quite a LOT of other things he packs with it) is 19386, so roughly double the amount of code in this C version.
Who could've predicted the "latest and greatest" would be inflated to morbid obesity ?
Good to know!
@Robinson Dorion As those go nowadays in the hundreds of thousands and millions of lines of code, I guess we could call this one merely pre-diabetic perhaps!
@Jacob Welsh Thanks for the question, yet again. For whatever reason I never bothered to write up anything on it but looking at it now, I rather should have written something after reading through all that code, certainly.