News:

Download Pelles C here: http://www.pellesc.se

Main Menu

Github-kuba miniz for Pelles C

Started by John Z, November 25, 2025, 12:01:37 PM

Previous topic - Next topic

John Z

11/25/2025

This is GitHub-kuba miniz 3.0.2 with minor modifications for Pelles C

Minor changes to compile in Pelles C Version 13 (and probably earlier versions)
All changes annotated with //ZZ

Build Notes:
If file time&date/functions are NOT needed define MINIZ_NO_TIME
If time&date is wanted then the /Go (Define compatibility names) option in Pelles
must be used.

Many build warnings - no errors of course.  Tested zip a file, unzip a file, also
a miniz zipped file was able to be unzipped with Windows itself as well as 7z.
Tested unzip to memory as well.

Did not try using any Pelles C optimizations.  Suggest using
#pragma optimize( none ) in the three source files if using optimizations elsewhere


Also example usages are included from kuba.

John Z

John Z

Has anyone gotten the newest release version 3.1.1 of Github-kuba miniz to build in Pelles C?

https://github.com/kuba--/zip

Has new features as well as 64bit capability.

John Z

TimoVJL

#2
You have to modify sources a bit ?
miniz.h line 5451
from
#ifdef _MSC_VER#if defined(_MSC_VER) && !defined(__POCC__)

zip.c line 42
#if defined(_MSC_VER) && !defined(__POCC__)
May the source be with you

Vortex

Hi Timo,

It look like that compiling new version is not so easy. A lot of warnings and error messages.
Code it... That's all...

Vortex

Code it... That's all...

John Z

Thanks Timo,Vortex,

Yes I had that one and several other changes similar to what I did for 3.0.2
It is creating a zip file that can be opened with both Windows Explorer and 7z.

However there is something amiss.  Both LibreOffice Calc and Excel complain of a corrupted zip, but both will 'repair' it and open with all the data intact.

So it seems like something not quite right in the header, or other housekeeping part.  Checking the actual zipped files from an 'old' version and in the new 3.1.1 version shows the files themselves are identical.

Maybe I'll just start over - But I'll try your work first  :)

Thanks,
John Z



TimoVJL

A simple example:#include <stdlib.h>
//#include <zip.h>
#pragma comment(lib, "zip.lib")
//#include "zip_stdcall.h"
#define ZIP_DEFAULT_COMPRESSION_LEVEL 6
typedef struct zip_t zip_t;
extern struct zip_t __stdcall *zip_open(const char *zipname, int level, char mode);
extern int __stdcall zip_entry_open(struct zip_t *zip, const char *entryname);
extern int __stdcall zip_entry_fwrite(struct zip_t *zip, const char *filename);
extern int __stdcall zip_entry_close(struct zip_t *zip);
extern int __stdcall zip_close(struct zip_t *zip);

int __cdecl main(void)
{
struct zip_t *zip = zip_open("meta.zip", ZIP_DEFAULT_COMPRESSION_LEVEL, 'w');
{
    zip_entry_open(zip, "meta.xml");
    {
        zip_entry_fwrite(zip, "meta.xml");
    }
    zip_entry_close(zip);
}
zip_close(zip);
return 0;
}
May the source be with you

Vortex

Hi Timo,

Great work, thanks. Based on your sample, here is a modified version creating the archive test.zip and adding the file sample.docx

#include <stdlib.h>
//#include <zip.h>
#pragma comment(lib, "zip.lib")
//#include "zip_stdcall.h"
#define ZIP_DEFAULT_COMPRESSION_LEVEL 6
typedef struct zip_t zip_t;
extern struct zip_t __stdcall *zip_open(const char *zipname, int level, char mode);
extern int __stdcall zip_entry_open(struct zip_t *zip, const char *entryname);
extern int __stdcall zip_entry_fwrite(struct zip_t *zip, const char *filename);
extern int __stdcall zip_entry_close(struct zip_t *zip);
extern int __stdcall zip_close(struct zip_t *zip);

int __cdecl main(void)
{
    struct zip_t *zip = zip_open("test.zip", ZIP_DEFAULT_COMPRESSION_LEVEL, 'w');
    {
        zip_entry_open(zip, "sample.docx");
        {
            zip_entry_fwrite(zip, "sample.docx");
        }
        zip_entry_close(zip);
    }
    zip_close(zip);
    return 0;
}
Code it... That's all...

John Z

Thanks Timo, Vortex,

Well surprising results.  I built your version.  Very good I had not thought to use __MINGW32__ so my build ended up with more code 'customizations'. 

However, when I used your version to create an ODF spreadsheet it ended up with the same exact issue!  Note that I have been using using an older version of miniz to do the same thing successfully, so any issue is only related to the new miniz.

Just like with my mod of miniz, both ODF and Excel indicate a problem which they both can  'repair' and all spreadsheet data is there. Whereas Explorer ZIP, and 7z have no issue unzipping the file, and show no error report.

So there is some sort of (minor repairable) incompatibility with ODF/Excel expectations when using the newest 3.1.1 64 bit capable version.  I did try it with the 32 bit fileopen ('w'-64) and it was the same.

Looks like I'll be sticking with the old perfectly working version for now...at least until I can spend time to figure out the difference.

John Z

TimoVJL

#9
John Z,
can you give a small example file for tests with Libre Office and MS Office ?
May the source be with you

John Z

#10
HI Timo,

Sure here are two files _good is with the older version, _311T is with the current version.
The headers are different - The compressed data itself for the files looks fairly much the same on a quick check.  The file sizes are different too when looking at the actual. Both versions open in 7z without complaint.

Both files used the same source data and same program except swapping zip procs -
good file is 3,703 bytes
not so good file is 3,938 bytes

John Z

LibreOffice 25.8
Excel 2010

TimoVJL

#11
That A_BaseFile_imp_T_311T.ods is 64bit zip, perhaps a reason why it isn't accepted.
May the source be with you

John Z

#12
Oh yes, I did try using the ('w' - 64) attribute to open as 32 bit with my version.
Convention:

    Use 'w' - 64 (integer value 55) when calling zip_open, zip_stream_open, etc., to select write mode without enabling ZIP64.
    The same pattern applies to other modes: use 'r' - 64, 'a' - 64, 'd' - 64 to pick the non-ZIP64 variants.

I will try that again, with your version, and post.

Thanks,

John Z

Update: Created with 'w' - 64  (but I'm not sure how to really tell if 32bit or 64bit ZIP)  using 7z Info does not show as 64 bit while prior version does, so this must be 32 bit.  It has the same symptom.

TimoVJL

#13
Libre Office opens a that A_BaseFile_imp_T_32bit.ods normally.

May the source be with you

John Z

Thanks Timo,

Quote from: TimoVJL on Yesterday at 07:30:25 PMLibre Office opens a that A_BaseFile_imp_T_32bit.ods normally.

Can you let me know what LibreOffice version you have?

Thanks,
John Z

P.S. for excel you must right click on the file and choose Open With Excel.