Zip support: integrating minizip into vcmi

International board Development
#1

Hi. I’d like to implement .zip support for vcmi (mostly for mods).

It seems that most easiest way to do this is to use minizip library: winimage.com/zLibDll/minizip.html
This library depends only on zlib which is already used by vcmi.
The problem is that this library seems to be unavailable in most of Linux distributions. This means that we need to provide it alongside with vcmi. Since library is really small this won’t be a problem.

What I’d like to do is to:

  • add minizip into vcmi trunk. Probably at lib/minizip
  • add implementation of resource loader interface into vcmi library so zip’s can be loaded just like H3 archives

Question is: how minizip should be linked with vcmi library? Dynamic library, static library or just include those few files from minizip into vcmi library?
I prefer having dynamic library so it can be easily disabled if minizip is already installed but if there are some issues I’m not aware of I’m OK to switch to another method.

#2

Definitely as a library, with build time detection of system wide library existence. When provided vcmi/lib/minizip is used you shall install resulting dynamic library into %_libdir/vcmi and use rpath in vcmi lib, or build it in as static. Including anything into VCMI library sources is the worst thing you can do.

#3

I’m trying to compile that on Windows. It seems that type of

    const z_crc_t* pcrc_32_tab;

is undefined.

#4

That comes from zip.c?

Right now this file is not needed by vcmi - compiling unzip.c and ioapi.c is enough.

unzip.h uses that struct too but it has been disabled via preprocessor. Similar code can be used in zip.h:

#ifndef NOCRYPT
        #define NOCRYPT
#endif
#5

I have some serious problems linking minizip as dynamic library. To do that, I need .lib object file, which should be generated by MSVC. Still, it doesn’t appear. According to internet sources, this may happen if no functions are exported, like this

__declspec(dllexport)

Indeed, zconf.h defines the following (just nothing)

#ifndef ZEXPORT
#  define ZEXPORT
#endif

Still, not sure if and how should I override it, or the issue is somewhere else

#6

My guess is that you should define ZEXPORT in project settings. gcc format is -DZEXPORT="__declspec(dllexport)", don’t know about VS.

#7

That was the issue indeed, I just didn’t notice important detail last time. Now it works.

#8

same issue here. how exactly did you fix it? Better yet, could you commit?

#9

Well, I already commited what worked for me. You may need to add new project to solution manually, as mine is completely out of sync.

#10

I have made changes to the required projects (lib + minizip), I have added the minizip to solution, added VCMI_DEBUG property sheets (for path inheritance), but now I am stuck on minizip with:

Error	3	error LNK2019: unresolved external symbol _inflate referenced in function _unzReadCurrentFile	C:\Home\Krs\Work\VCMI\trunk\minizip\unzip.obj	minizip
Error	4	error LNK2019: unresolved external symbol _inflateEnd referenced in function _unzCloseCurrentFile	C:\Home\Krs\Work\VCMI\trunk\minizip\unzip.obj	minizip
Error	5	error LNK2019: unresolved external symbol _crc32 referenced in function _unzReadCurrentFile	C:\Home\Krs\Work\VCMI\trunk\minizip\unzip.obj	minizip
Error	6	error LNK2019: unresolved external symbol _inflateInit2_ referenced in function _unzOpenCurrentFile3	C:\Home\Krs\Work\VCMI\trunk\minizip\unzip.obj	minizip

Probably the same ZEXPORT, but I am clueless on how to fix it.

#11
  • minizip should include 2 or 3 *.c files: ioapi.c, unzip.c and optionally zip.c. Nothing else
  • minizip library itself must be linked against zlib
  • vcmi library must be linked against minizip.

I think that you’re missing point #2.

#12

ok. solution + minizip and lib projects fixed for compile with VS2012. Can someone with rights apply the patch?
VS2012 compile fix.zip (1.83 KB)

#13

Hi,

minizip doesn’t have a licence. Code without a license shouldn’t be pulled in.

Why not use physicsFS instead ? icculus.org/physfs/
It seems to be do what you want, has a compatible license, is present on most linux distributions, and works on about every OS.

#14

physfs is used by asc, blobby2, lincity-ng, tmw and warzone2100 (and some not games like SDL_sound or paragui). OTOH minizip is used by chromium (web browser), libdigidocpp, psi (communicator) and VLC - it seems to be more generic, so physfs designed especially for game archives purpose should be more suitable.

#15

ubuntux, minizip uses zlib license. This is stated in (some of) source files and in info file:
svn.code.sf.net/p/vcmi/code/trun … ip/unzip.h
svn.code.sf.net/p/vcmi/code/trun … 4_info.txt
In fact minizip is part of zlib - version in trunk comes from latest zlib package.

As for physfs not sure. Main physfs purpose is to create virtual file system - pretty much what we already have in lib/filesystem. Judging from code it does not looks like we can just take .zip support from it - too integrated in the rest of code. And we can’t replace our own VFS with it - for example we need H3 archives that use custom format to be part of VFS as well - physfs does not allows extensions. Our VFS allows “mounting” archives at any path, physfs allow mounting only at root.

#16

I committed project files and changes to minizip that made it working on my installation.
Let me know if they work for you — I wasn’t able to get it working with Warmonger’s project files (even with krs’ patch)

#17

Thanks Ivan. I had looked in several files and the homepage, and couldn’t find one. So it’s all good.

#18

By the way, is current mod system permits only one folder, from where mods are loaded?
Or is it possible to use 2 or more paths where mods will be stored?

I ask because now I have some final mods (like Cove) and mods-in-progress.
It will be great if user can store zipped completed mods in one folder and others in second folder (or there can be more folders).
Or it is too much work for filesystem?