Lubomir I. Ivanov
neolit123 at gmail.com
Mon Jan 6 05:00:10 UTC 2014
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
>> 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
it uses zlib license:
i think we only need the zip.c/h, unzip.c/h, ioapi.c/h from this folder:
More information about the subsurface