IIRC Dynazip coded the zip routines included in Windows since XP (so Sergeys "pretty good" certainly is true there) but at least once back in history argued that programmatic of those routines via Scripting Object violated licensing agreement with MS. No idea how solid that legal argument is/was or current license holders still raise the issue - but something to consider as Open Source versions and cheap wrappers for COM and also in vfp source code exist. Back then I owned a license for Dynazip as well as some other controls. Not knowing if future Win versions might impact usage of bought version Dynazip ( [a]COM sometimes barfs when trying to install older versions, [b] if you ask for default interface instead of versioned one you might get a version not covered by license bought by you, but included in current windows - undocumented/unlicensed...) and being deurinted by such (in my opinion) multiple licensing attempts I refrained from using Dynazip unless customer specs those routines overriding my objections.

I KNOW I am safe automating 7zip or WinRAR commandline, same goes for using Open Source Dll directly or with cheap, bought vfp Zip wrapper from dFpug - there will be no repercussions if a customer decides "suddenly" that licensing is an issue and I have a clean conscience even when using those routines only in house, where it is almost certain no legal problem will rise.

Certainly worth the effort to either wrap Open Source C dll yourself or "spend" $50 for fll including minimal enhancements to OS C zip code plus ready-to-use vfp code to wrap with or without accompanying GUI with easy to grok code and documentation- at least in my book.

In the dFPug version I mentioned you have a hook ( more exactly a *real synched callback, pausing C-code during callback execution in vfp code* from internal C even if working from a list or wildcard...) called before and after each file being added. Inside the hook you know the # files, current zip size, path and name of next/last file, can set up counters to estimate compression for specific file type - for instance mostly text fielded dbf compresses 50 - 75%, mostly dependend on amount of Space() in your fields, whereas INT fields with high selectivety (many or discrete values) will not compress much.
Controlled the feeding mostly via directories only, as we had directories each good for a couple of 100 MB, reading into a cursor first and trying to estimate chunks to add via wildcarded names - that I coded.
Back when CD was the norm, DVD readers and writers were still costly and did not support all DVD formats (+R, -R, +RW, -RW, -RAM and so on) and I had to send GBytes of compressed data, I used the minimally subclassed dFPug code to split the resulting zip files over several CDs when the next file to be added was likely to surpass disc capacity.
Tweaked code later on for single and double layer DVD, but was seldom forced to insert second double DVD ;-)

If you have LOTS of small files, be certain to tweak the callback to update the GUI only every 20 to 100 files: I had dynamically set values depending on total count of files and amount of total data to be added, as the vfp GUI updates slow down the creation of Zip compared to pure C execution BY A LOT. If you are compressing .bat, .txt, .Bmp or .com files, each only a few bytes or KB each, you can expect a speedup factor of 50-100 (!) if NOT showing statistics for each processed file in the GUI. Rule of thumb for me was at least 1 update every 120 seconds, every %% of processed total data volume and every %% of calculated total file count - we had # of txt files up to eight digits. This made certain that GUI time did not add significant "person waiting" time but you saw at least after each second minute and executed single file add an update to several screen numbers. A couple of thousand updates in vfp GUI adds not that much time, a couple of million does ;-)

You must spend some effort to read the docs, but >90% of the problems are already solved, if you are lucky, only a few properties and threshold values will be needed for your special use case

IIRC you can get docs and time-limited version for free - you can code and test, but the source was given only after paying the (IMO well spent) $50 (fll only was "memberware"=free to members of dDPug, so free to me back then). Stingy me would probably have not checked if it had been not free with source for me (I had the version included with their vfx fwk back then and worked as a freelancer considerable H early this century for the biz company side of the user group - but I am certain your use case can be handled with it, if it can still be found.

my 0.02€

thomas

>>>>Is there a VFP tool with source code, free if available that would let me zip files?
>>>
>>>... and furthermore, anybody know of any that also has feature allow you to split a large ZIP into "chunks" of specific size (like you see with more modern ZIP/RAR utility) ? Am currently using (very) old copy of DynaZIP and occasionally running into situation where resulting ZIP file ends up running into 2GB size limit. It does have the feature to span across diskette -- but that isn't so helpful nowadays (since few if any computers feature floppy diskette, and even you did, we'd be dealing with a ridiculously large number of floppy diskettes)
>>
>>DynaZIP is pretty good piece of software. It still working after company that created it has been out of business for many years
>
>Indeed it is a good piece of software -- I've been looking at a replacement since I'm running into more situations where I'm running into the ZIP file limits. If there's no suitable replacement that has provision for "chunking," I'll probably have to figure out a scheme to set up "batches" (where I'm multiple separate ZIP files ()rather than a single one). The ugly bit is figuring out how to arrange the files within the individual ZIP archives so that I minimize the number of separate ZIP files while at the same time making sure not to run into 2GB size limits.
>
>Fortunately we're not storing stuff like pictures or document files within Memo fields (stopped doing that a long time ago when we discovered it was more trouble -- not only was the problem of memo bloat, but increased chance of corruption -- definitely a pain when you discover the memo pointers go wonky on you and stuff gets associated with the wrong records) -- otherwise we would've run into the file size limit long ago.