[VB6] Compression API: Another post-Win7 gem

Here is a wrapper class for the Compression API. This requires Windows 8 or newer.

It is used here in a simple demo, which creates a 2.5MB file test.txt which is then read back and run through compression and written out as comp.bin, and then that is read back and run through decompression and written as the expanded.txt file.

Writing the before and after files makes it easy to run WinDiff to verify results.

There is some work remaining to be done but the essentials are all working.

Caveat:

Programs that use this system DLL may be flagged as a trojan horse by antivirus software, even by Windows Defender. Malware droppers have gotten out of control so all security suites are tightening these things up a lot. When they see a VB6 program they turn on quite a few other checks, and your suspicion score can rise quickly. Blame the miscreants who started using VB6 to create their monsters.

The demo makes use of the simpler "buffer mode" of the Compression API, which Microsoft recommends for most uses anyway.

In this mode your program feeds "buffers" of data and each one gets compressed separately into a compressed "buffer" or "stream" that you would send over the network or write to disk as desired. These compressed BLOBs have the original length embedded into them, but they do not contain their own length.

The demo grabs big buffer chunks until the final chunk. It compresses each "chunk" and appends it to an output file, prefixing each with a length value to frame them for subsequent decompression.

Attachment 148097

That framing is done outside of the Compression API. You could use another scheme such as writing separate files or if the input file was small enough just compress the entire thing as a single buffer. As far as I can tell the Compression API algorithms all restart their "dictionaries" for each buffer. Note that if buffers are too small the degree of compression may suffer.


Of course after that it turns around and reverses the process to demonstrate decompression. That leaves us with the before and after files we can compare to verify that the lossless compression worked properly.

Quote:

---

Originally Posted by dilettante

Here is a wrapper class for the Compression API. This requires Windows 8 or newer.

It is used here in a simple demo, which creates a 2.5MB file test.txt which is then read back and run through compression and written out as comp.bin, and then that is read back and run through decompression and written as the expanded.txt file.

Writing the before and after files makes it easy to run WinDiff to verify results.

There is some work remaining to be done but the essentials are all working.

Caveat:

Programs that use this system DLL may be flagged as a trojan horse by antivirus software, even by Windows Defender. Malware droppers have gotten out of control so all security suites are tightening these things up a lot. When they see a VB6 program they turn on quite a few other checks, and your suspicion score can rise quickly. Blame the miscreants who started using VB6 to create their monsters.

---

i used win7.
i used
Private Declare Function RtlDecompressBuffer _
Lib "ntdll.dll" (ByVal CompressionFormat As Integer, _
ByVal ptrDestBuffer As Any, _
ByVal DestBufferSize As Long, _
ByVal ptrSrceBuffer As Any, _
ByVal SceBufferSize As Long, _
ByRef pDestinationSize As Long) As Long

Private Declare Function RtlCompressBuffer _
Lib "ntdll" (ByVal CompressionFormatAndEngine As Integer, _
ByRef UncompressedBuffer As Any, _
ByVal UncompressedBufferSize As Long, _
ByRef CompressedBuffer As Any, _
ByVal CompressedBufferSize As Long, _
ByVal UncompressedChunkSize As Long, _
ByRef FinalCompressedSize As Long, _
ByRef WorkSpace As Any) As Long

test.txt size:2.64m
comressed
test.bin size:1.59m

Here is a slightly re-worked version that more aggressively avoids buffer resizing. That gives some additional performance though not a lot since the resizing is mostly ReDim rather than ReDim Preserve anyway.

Could make a difference when working with very large amounts of data though.


Note that if you will be using VB6 native binary I/O you'll probably want aggressive resizing instead to be compatible with Get#/Put#. Then you can just omit the two optional parameters of both the Compress() and Decompress() methods.

We didn't have to do that here because of the "partial buffer" read and write supported by the HugeBinaryFile I/O class these demos use.

RtlCompressBuffer/RtlDecompressBuffer look like good options if you must run on unsupported downlevel systems.

I haven't tested the different compression algorithms with varying data types. Some may do better on text and others better on binary. Some use more RAM, some less. Some can be faster, others slower.

Good to know we have options.

I'm still surprised Microsoft hasn't exposed the Zip routines that Shell32 uses in its namespace extension zipfldr.dll though.

http://www.vbforums.com/showthread.p...t=#post5096951

I wasn't proposing this as a malware delivery technique but a way of programmatically compressing data for legitimate purposes. It is no wonder VB6 has to be considered suspicious by antivirus software these days. There are far too many script kiddies using it now.