dumping libzip

Martin Gysel me at bearsh.org
Mon Jan 6 06:28:12 UTC 2014


Am 06.01.2014 14:11, schrieb Dirk Hohndel:
> On Mon, 2014-01-06 at 15:00 +0200, Lubomir I. Ivanov wrote:
>> On 6 January 2014 14:50, Dirk Hohndel <dirk at hohndel.org> wrote:
>>> On Sun, 2014-01-05 at 21:57 +0200, Lubomir I. Ivanov wrote:
>>>> On 5 January 2014 17:26, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>>>>> On 5 January 2014 17:09, Lubomir I. Ivanov <neolit123 at gmail.com> wrote:
>>>>>>
>>>>>> i was recently looking for libzip alternatives, and minizip, which is
>>>>>> part of zlib was one, but looking at their sources i think i spotted
>>>>>> the same lack of _wopen() on win32.
>>>>>
>>>>> actually minizip has things like:
>>>>>
>>>>> WCHAR filenameW[FILENAME_MAX + 0x200 + 1];
>>>>> MultiByteToWideChar(CP_ACP,0,(const
>>>>> char*)filename,-1,filenameW,FILENAME_MAX + 0x200);
>>>>> hFile = CreateFile2(filenameW, dwDesiredAccess, dwShareMode,
>>>>> dwCreationDisposition, NULL);
>>>>>
>>>>> so i think we can now safely dump libzip, for good...
>>>>
>>>> and indeed we can, because the minizip API is apparently well designed...
>>>>
>>>> if you have a win32 box with mingw and zlib installed you can try the
>>>> attached test.c file:
>>>>
>>>> trying to open: c:\temp\éΓЯ€\test0.zip
>>>> open ok
>>>> trying to create: C:\Windows\TEMP/абвгд.zip
>>>> create ok
>>>>
>>>> a couple of points here; we need to:
>>>> - include a folder in subsurface named minizip that has the files from
>>>> zlib/contrib/minizip
>>>> this is the case because the contrib package is external to zlib and
>>>> the minizip interface is missing in zlib itself (AFAIK).
>>>> - convert all our libzip code to minizip wrapped functions in
>>>> windows.c, linux.c etc.
>>>>
>>>> and this pretty much solves the silly libzip situation.
>>>> as an alternative we can wait for libzip to fix this issue.
>>>
>>> What's the license this code is under? How much code are we talking
>>> about?
>>>
>>
>> it uses zlib license:
>> http://en.wikipedia.org/wiki/Zlib_License
> 
> Good - that's GPL compatible.
> 
>> i think we only need the zip.c/h, unzip.c/h, ioapi.c/h from this folder:
>> https://github.com/madler/zlib/tree/master/contrib/minizip
> 
> more than 5kloc :-(
> 
> I didn't mind absorbing things like the 320loc sha1 implementation from
> Linus. This seems a lot bigger. But then again, figuring out how to use
> get this correct as a dependency... I guess I'm mildly biased towards
> doing this.
> 
> Linus, what's your take?
> 
> Anyone else with a strong opinion?

I quickly skimmed through the ubuntu, fedora and gentoo pkg db:
fedora and gentoo seem to provide minizip library and headers [1,2], [3]
for ubuntu, I haven't found anything but as said, it was a quick search...

If you gonna bundle the minizip files, from a distribution point of
view, it would be nice if the bundled code is only used if needed or
even requested.

/martin

[1] https://apps.fedoraproject.org/packages/minizip
[2] https://apps.fedoraproject.org/packages/minizip-devel
[3] http://en.znurt.org/sys-libs/zlib  USE=minizip


More information about the subsurface mailing list