Do you use DynaZip AX (the ActiveX component)? Then you actually don't need a replacement. When using OLE classes you instanciate anything in a new process anyway, no matter if it's an OCX, DLL or EXE, as it usually is foreign language code anyway you start a new runtime process for an ActiveX component.
If not, you could also continue using Dynazip by creating your own 32bit COM Server to use with VFPA, either in VFP9 or VFPA 32Bit. This can be your streting point for that, in a 32bit VFP Project:
Code:
Define Class Zip as Custom OlePublic
Procedure Zip(tcDirectory)
* Your code zipping a directory with DynaZip
EndProc
Procedure Unzip(tcZipFile, tcTargetDirectory)
* Your code unzipping a zip file with DynaZip
EndProc
EndDefine
If you call the project Dyna.pjx and build (EXE or DLL, doesn't matter much) your VFP COM Server will be called "Dyna.ZIP".
Otherwise I second Griffs recommendation of BandiZip, though I have not used it. From the product description I see it offers everything you could use with DynaZip, including AES encryption, multiple archive formats support, file spanning, etc.
If you merely zip up some files so you can mail them and the end user of that ZIP does use whatever ZIP software to unzip it, the usage of the shell.application for that is completely sufficient. The only downside and some exotic problem cases you can find here on tek-tips is about progress of the zipping and too early trying to use the not yet completely written ZIP file, you have to understand using shell.application by createobject (OLE/COM automation) is making that a parallel process, which means this works in parallel. The code sample of ggreen does refrain from making much use of that, it merely waits with Sleep until the zipping or unzipping finihes with each single file. At these stages of the code you could also report progress, by the way, at least on which number of file you're working on.