dumping libzip

Lubomir I. Ivanov neolit123 at gmail.com
Sun Jan 5 11:57:10 UTC 2014


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.

opinions?

lubomir
--
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: text/x-csrc
Size: 2562 bytes
Desc: not available
URL: <http://lists.hohndel.org/pipermail/subsurface/attachments/20140105/ffdf5e0c/attachment.c>


More information about the subsurface mailing list