>>>I have not tried it, but what happens when a tool such as WinZip (32 bit version) tries to create a zip greater than 2G? I would suspect that the problem is with 32-bit and the ability to access files greater than 2G in size (2**32). If this is the case then you will have to use a shell command and a 64-bit version of a zip compressor to create the zip archive file that is greater than 2G. You cannot call any active-x component that is 32-bit to create files greater than 2G.
>>
>>32 bits is 4G, not 2G.
>
>Greg is basically right, although as you point out he probably meant 2**31 (or maybe 32-bit unsigned int).
>
>With rare exceptions, 32-bit user mode processes get only 2GB address space: http://technet.microsoft.com/en-us/library/ms189334%28v=sql.105%29.aspx . Clearly, some 32-bit processes can handle files larger than 2GB or even 4GB (SQL Server databases, large Outlook .PST files etc.) but as I understand it that requires (in Win32, anyways) using API calls which support that.
>
>VFPCompression is based on or is a wrapper around ZLib ( http://www.zlib.net/ ). The ZLib docs claim it works fine with any amount of data on 32- or 64-bit platforms but notes some limitations depending on compiler used (which in turn would mean platform as well, at least to some extent). As I see it there are several possibilities as to why this problem is showing up with VFPCompression:
>
>- Limitation or bug in ZLib (unlikely)
>- Limitation or bug introduced by Craig while FLL-izing ZLib or compiling the final end product
>- Limitation or bug in how much data can be handled in the interface between the FLL and VFP. There is no system capacity in VFP that is larger than 2GB (e.g. Maximum file size accessible via low level file functions).

Craig's FLL use base functions (32 bit file access) for zipping/unzipping files.