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
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
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__)
Hi Timo,
It look like that compiling new version is not so easy. A lot of warnings and error messages.
Hi Timo,
Great work, many thanks.
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
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;
}
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;
}
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
John Z,
can you give a small example file for tests with Libre Office and MS Office ?
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
That A_BaseFile_imp_T_311T.ods is 64bit zip, perhaps a reason why it isn't accepted.
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.
Libre Office opens a that A_BaseFile_imp_T_32bit.ods normally.
Thanks Timo,
Quote from: TimoVJL on April 22, 2026, 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.
LibreOffice 7.1
MS Office 2010
Thanks Timo,
I appreciate, very much, all of your help!
John Z
Source code reviewed to remove some unnecessary struct statements :
#include <stdlib.h>
#pragma comment(lib, "zip.lib")
#define ZIP_DEFAULT_COMPRESSION_LEVEL 6
typedef struct zip_t zip_t;
extern zip_t __stdcall *zip_open(const char *zipname, int level, char mode);
extern int __stdcall zip_entry_open(zip_t *zip, const char *entryname);
extern int __stdcall zip_entry_fwrite(zip_t *zip, const char *filename);
extern int __stdcall zip_entry_close(zip_t *zip);
extern int __stdcall zip_close(zip_t *zip);
int __cdecl main(void)
{
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;
}
Why not do bit more
int __cdecl main(void)
{
zip_t *zip = zip_open("test.zip", ZIP_DEFAULT_COMPRESSION_LEVEL, 'w');
if (zip) {
zip_entry_open(zip, "sample.docx");
zip_entry_fwrite(zip, "sample.docx");
zip_entry_close(zip);
zip_close(zip);
}
return 0;
}
QuoteOptional features
The library supports three compile-time flags to strip unused functionality and reduce binary size. All features are enabled by default -- if you just drop the source files into your project and compile, everything works as before.
https://github.com/kuba--/zip
A miniz main problem is, that it is one file and not easy to split modules for static library.
msvc have a -Gy option for that.
This tool can help with modified source code:
split source file using tags (https://forum.pellesc.de/index.php?msg=28079)
Just have an another tool to add tags a new version of code.
Adding this line to the top of zip.c and rebuilding the static library :
#define ZIP_ENABLE_INFLATE 0
The size of my test executable dropped from 138K to 134K.
Test projects without library for testing defines.
First project with static crt and second with pocrt.dll, so actual code size seen.
Well newer versions of miniz definitely work, but seems some incompatibility with some programs.
This newest version does not cleanly work with LibreOffice 25.8, or Excel 2010 (both will 'repair' the file and then are OK) but DOES work with LibreOffice 7, without repair (as Timo pointed out above, and I've verified as well). Yet a quite a bit older version of miniz works for both newer LibreOffice, older LibreOffice, and Excel several generations, no repair, no errors.
Newer miniz zipped file open ok with miniz definitely, and with Windows Zip and 7z as far as I can tell.
It is a conundrum!
The one thing I see in a Hex display/comparison is that the newer version of miniz appears to be appending to the filenames 01000000 maybe some sort of padding? When using Windows built in ZIP or using 7z, or using the older version of miniz these bytes are not there. The resulting spreadsheet from these three methods all open OK no repair needed.
So this is just a caution in using miniz created zip files in other applications, some may not be compatible. Sadly I'll just have to stick with the older miniz version for now.
John Z
Have you ever looked at this?
https://zlib.net/
My main interest is in the compression/decompression part, which has worked well for me since the 1990s, but I think there is some attempt somewhere in this package to handle ZIP files...
I'm not sure this will solve anything, but if you are stuck ...
Thanks, I'll give it a look.
John Z
Using zlib does not look easy. Anyone who tried the latest version?
Looks like there is a possible path using ZLib which might make it easier.
ZLib has a miniz like version minizip
So I might be able to implement, or at least try -
Two links:
Base -
https://www.winimage.com/zLibDll/minizip.html
This seems A good helper set of functions, similar to miniz -
https://nachtimwald.com/2019/09/08/making-minizip-easier-to-use
John Z
Extracting the contents of a zip file with COM \ Component Object Modeling is possible. Later, I can post an example.
Yes, I read COM could do zipping and unzipping but not quite simple.
My particular requirement at this time is to be able to create and add files to a zip file, but I'm sure your example will be useful to other interested people. Good code examples help everyone 👍
John Z
Hi John,
The problem is to understand the cascading external dependencies of the zip libraries. One external function could point another one and the another one to another function\ structure or specific equate etc. It would be good to be find a zip library usable with Pelles C and Poasm.
In year 2008 a LiteZip was small and easy to use.
Files at https://forum.pellesc.de/index.php?msg=42339 (https://forum.pellesc.de/index.php?msg=42339)
It was used in Add-In too.
https://forum.pellesc.de/index.php?topic=3260.msg12307#msg12307 (https://forum.pellesc.de/index.php?topic=3260.msg12307#msg12307)
At some point it change lisence to LGPL and then it was abandoned ?
Hi Timo,
Thanks, I am going to test your project.
Hi Timo,
The command line zip tool works fine. Do you have the static library version of unzip?
That example use only additional LiteZip.lib and msvcrt.lib
A msvcrt was used to show actual code size.
Hi Timo,
Could you provide the file LiteUnzip.h ? I think this one is missing.
So it was missing from LiteUnzip package :(