dumping libzip

[Dirk Hohndel]

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?

/D