News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

zlib

Started by jj2007, July 09, 2012, 03:53:51 AM

Previous topic - Next topic

jj2007

I have a zip & unzip app on my todo list. After a quick attempt in the installer thread, I investigated a bit into zlib, and my impression is that the lib is powerful but kind of messy.

For example, there seems no straightforward way to get file info (time & date, size)  of individual files in zlib1.dll (the 1 stands there for historical reasons - zlib.dll was buggy, apparently, so they chose zlib1.dll to distinguish good code from bad code :eusa_boohoo:)

Intense researchTM leads to a function called unzGetCurrentFileInfo which can extract vital info; however, it is badly documented, and nope, it's not included in zlib1.dll. Further intense researchTM finds unzGetCurrentFileInfo in zlibwapi.dll (the wapi seems to stand for "Windows API"). It is also contained in zlibstat.lib ... undocumented, of course.

Then there are MiniZip and MiniZ based on zlib, which seem to be wrappers or clones or whatever, it is all a bit opaque.

Alternatively, there is Igor Pavlov's LZMA SDK, source code available, lots of interesting error messages when used with Visual Studio - many nights of fun solving mysteries in options and header files and the like guaranteed. No DLL or lib files, though, and Igor apologises occasionally for lousy documentation...

Does anybody have experience to share, especially documentation?? Zlib does not offer the highest compression ratios, but at least it looks feasible...

Ficy

Actually the entyre 7Zip library is opensource it even has some interesting MASM code in it. :eusa_dance:

Like how to calculate CRC32 with a smarth macro-set to compile 32/64 bit respectivelly.

jj2007

Quote from: Ficy on July 09, 2012, 06:27:17 AM
Actually the entyre 7Zip library is opensource...

Great. So your C compiler doesn't throw error messages? Could you produce a lib or obj file from the source?

In the meantime, I found a partial manual here, and discovered that gzwrite returns different values when used from zlib1 (correct #bytes) resp. zlibwapi (too high). But it works fine with both dlls.

Ficko

QuoteCould you produce a lib or obj file from the source?
Of curse.

1.) Open a VisualStudion Command promt for 32-bit build.
2.) Go to "k:\CPP\7zip\Bundles\Format7zF\" - Assuming you unpaked the package on "k:\" -
3.) Execute "nmake NEW_COMPILER=1 MY_STATIC_LINK=1" - for example depends what you wanna make -

;)

Ficko

Just to make sure:
I am not talking about the "LZMA SDK" I am talking about the "7-Zip Source code" but I assume the SDK has a simile concept for build.

jcfuller

If zip is not mandatory:
http://www.ibsensoftware.com/products_aPLib.html
I've used aPLib  with a number of languages ( I assume I used masm/jwasm at one point but where the code is???)
James

jj2007

James,

Thanks for reminding me. I used ApLib a long time ago with GfaBasic (16-bit!).
Most of the time I will just shuffle my own data around, so ApLib would be an option. On the other hand, being compatible to the zip world would be an argument for zlib... will see.

Jochen

fearless

http://www.winimage.com/zLibDll/minizip.html

download the zlib125dll.zip and extract files

under /static32 folder you will find a zlibstat.lib

RadASM 3.0 source shows examples of using it with update plugin, and i think i remember a zlibstat.inc file being available there that has the protos defined for use in the library.



jj2007

Thanks, fearless. I eventually found zlibstat.inc at http://www.masmforum.com/archive2005/zlibstat.inc.zip
There is one thing that intrigues me:

curfile_info      STRUCT
stream      z_stream      <>
stream_initialised   SDWORD      ?
pos_in_buffered_data   DWORD      ?
pos_local_header   DWORD      ?
central_header      DWORD      ?
size_centralheader   DWORD      ?
flag      DWORD      ?
method      SDWORD      ?
raw      SDWORD      ?
buffered_data   Byte      16384t DUP (?)
dosDate      DWORD      ?
crc32      DWORD      ?
curfile_info      ENDS


Is the "t" a typo, or does it have some special meaning?

Another problem is that the linker complains about not finding uuid.lib :(
When adding uuid.lib from PellesC, the linker complains about unresolved _main. Oh well.

MichaelW

I could not find binaries for zlib 1.2.7, so I started with the zlib125dll.zip from here:

http://www.winimage.com/zLibDll/index.html

And using pexports (from an older version of MinGW) I got this DEF file for the 32-bit zlibwapi.dll:

LIBRARY zlibwapi.dll
EXPORTS
adler32
adler32_combine
compress
compress2
compressBound
crc32
crc32_combine
deflate
deflateBound
deflateCopy
deflateEnd
deflateInit2_
deflateInit_
deflateParams
deflatePrime
deflateReset
deflateSetDictionary
deflateSetHeader
deflateTune
fill_win32_filefunc
fill_win32_filefunc64
fill_win32_filefunc64A
fill_win32_filefunc64W
get_crc_table
gzbuffer
gzclearerr
gzclose
gzclose_r
gzclose_w
gzdirect
gzdopen
gzeof
gzerror
gzflush
gzgetc
gzgets
gzoffset
gzopen
gzprintf
gzputc
gzputs
gzread
gzrewind
gzseek
gzsetparams
gztell
gzungetc
gzwrite
inflate
inflateBack
inflateBackEnd
inflateBackInit_
inflateCopy
inflateEnd
inflateGetHeader
inflateInit2_
inflateInit_
inflateMark
inflatePrime
inflateReset
inflateReset2
inflateSetDictionary
inflateSync
inflateSyncPoint
inflateUndermine
uncompress
unzClose
unzCloseCurrentFile
unzGetCurrentFileInfo
unzGetCurrentFileInfo64
unzGetCurrentFileZStreamPos64
unzGetFilePos
unzGetFilePos64
unzGetGlobalComment
unzGetGlobalInfo
unzGetGlobalInfo64
unzGetLocalExtrafield
unzGoToFilePos
unzGoToFilePos64
unzGoToFirstFile
unzGoToNextFile
unzLocateFile
unzOpen
unzOpen2
unzOpen2_64
unzOpen64
unzOpenCurrentFile
unzOpenCurrentFile2
unzOpenCurrentFile3
unzOpenCurrentFilePassword
unzReadCurrentFile
unzStringFileNameCompare
unzeof
unztell
unztell64
zError
zipClose
zipCloseFileInZip
zipCloseFileInZipRaw
zipCloseFileInZipRaw64
zipOpen
zipOpen2
zipOpen2_64
zipOpen64
zipOpenNewFileInZip
zipOpenNewFileInZip2
zipOpenNewFileInZip2_64
zipOpenNewFileInZip3
zipOpenNewFileInZip3_64
zipOpenNewFileInZip4_64
zipOpenNewFileInZip64
zipWriteInFileInZip
zlibCompileFlags
zlibVersion


I'm assuming that the static library contains the same functions, but I have not tested this.

I tried to use Japheth's h2incx to convert zlib.h and zconf.h from the 1.2.5 source, but when I tried to assemble an ASM source, that did not reference anything in the include files, but with the files included, I got one error for zconf.inc, and after I eliminated that ~90 errors for zlib.inc.
Well Microsoft, here's another nice mess you've gotten us into.

Vortex

If I am not wrong, Masm32 v7 provided uuid.lib

fearless

QuoteIs the "t" a typo, or does it have some special meaning?

I have the same thing in my .inc file, weird. I would assume as well that its a typo.

Other older post in the archive forum in relation to using gzipinflate (with the zlib library): http://www.masmforum.com/board/index.php?topic=9039.0

jj2007

Thanks, fearless and Vortex. I will have a closer look, although I am tempted to stick with the current MasmBasic implementation because FreeArc is just incredibly efficient - see http://www.maximumcompression.com/data/summary_mf.php#data

The downside is there is no dll - you are forced to use the FreeArc executable, and that costs quite a bit of milliseconds...

include \masm32\MasmBasic\MasmBasic.inc   ; download
  Init
  GetFiles \Masm32\m32lib\*.asm   ; load Files$() array
  push eax         ; save # of files
  NanoTimer()
  ZipFiles "Lib32"   ; the name of the *.arc archive
  pop eax
  Inkey Str$("%i files compressed", eax), Str$(" in %i ms\n", NanoTimer(ms)), "See details (y)?"
  .if eax=="y"
      Launch ExpandEnv$(Chr$(34, "%ProgramFiles%\FreeArc\bin\Arc.exe", 34, " v Lib32.arc"))
      Inkey
  .endif
  Exit
end start

The resulting arc file is 55951 bytes, as compared to 191020 for WinZip's max portable mode. And FreeArc is still twice as fast...!

The v option, by the way, is meant for developers and produces archive info:
Listing archive: Lib32.arc
Date/time              Attr            Size          Packed      CRC Filename
-----------------------------------------------------------------------------
2000-06-02 16:24:14 .......            1364           48790 c2249beb Masm32\m32lib\a2dw.asm
2004-05-21 07:38:48 .......            3399               0 50c16759 Masm32\m32lib\a2dw_ex.asm
2004-03-29 11:15:22 .......            1221               0 7ee82d23 Masm32\m32lib\a2wc.asm
2003-01-12 07:01:56 .......            6833               0 b1818c69 Masm32\m32lib\about.asm
2006-07-04 09:01:38 .......            3749               0 69296e9a Masm32\m32lib\acisort.asm


P.S.: You need %ProgramFiles%\FreeArc\bin\Arc.exe to get the attachment working. Another weak point of FreeArc.

hfheatherfox07

#13
Quote from: fearless on July 09, 2012, 10:05:31 AM
http://www.winimage.com/zLibDll/minizip.html

download the zlib125dll.zip and extract files

under /static32 folder you will find a zlibstat.lib

RadASM 3.0 source shows examples of using it with update plugin, and i think i remember a zlibstat.inc file being available there that has the protos defined for use in the library.

First off the whole point I think is making a zip-unzip with zlib
Not another compression method ( there are a few)
I have tried this wich I have found on another site as a base start

http://www.asmcommunity.net/board/index.php?topic=6863.0

First I am wondering why not use the zlib.dll? If we get that working than try a .lib version!

Second thing is... In the zlib125.dll there is a demo zip-unzip which you need to run with a batch file
And they don't use commands like "compress"  they use "inflate" deflate" if I am not mistaken.
It would be cool to make a simple zip-unzip using zlib
But I think we sould try the above example with a .dll for now they seem to have a working copy!


I added that example with all the lib's needed... so you don't have to hunt for them
Your code and your skills will be assimilated. Your programming language is irrelevant.
We are the ASM Borg and you will become part of us. Compile and be assembled.

fearless

#14
Been playing around with the zlib static library and looking at KetilO's code for a while and decided to put together a basic Extract (Inflate/Expand/Unzip or whatever you want to call it) function. I've packaged it into a small lib file for handyness. Source is included as well. I'm hoping to expand on it by implementing a few other options at a later date. But i figured it would be worth uploading, and letting peeps take a looksee at it. I've wrote some stuff about it on my website/blog thingy. If anyones interested feel free to take a look (website link in sig)

Done some limited testing, but usual disclaimer applies, so maybe be careful with it, you dont want to overwrite any important files! :D

Include zlibextract.inc
Includelib zlibstat.lib
Includelib zlibextract.lib

.code
Invoke ZL_Extract, Addr szZipFile, Addr szFileNameOrFileSpec, Addr szOutputFolder


1st param is the name of your zip file, 2nd and 3rd param are optional.
If 2nd param is NULL assumes '*.*' = all files. Can be a specific filename or wildcards ? * (well, hopefully it should)
If 3rd param is NULL assumes '.\' = current folder. Should handle relative paths stored in the zip and output with them appended to specified outputfolder (or current folder+internalpath) if NULL specified. (Again hopefully)

Anyhows, feel free to test away, throw stones at it, shout at it, then crawl over to it in a drunken stupor and hug it, before passing out. Have fun.

Update 18.04.2013 15:49pm: Fixed 2 bugs. Fingers crossed it works ok now.