Compression in VB6: modern solutions

Overview:

This project provides convenient VB6 wrappers for multiple compression APIs, including zLib, zLib-ng, zstd, lz4, and the Microsoft Compression APIs (Win 8+). A small sample project allows you to compare compression time, decompression time, and compression ratio across all libraries. Just drag+drop a file onto the text box to test it.

This project is also available on GitHub. The GitHub version may have additional improvements and features not available here (because the project is too large to fit within vbforums attachment size limits).

Long version:

Compression has never been an easy task for VB developers. Until Windows 8, Microsoft provided very little support for it, and while 3rd-party solutions have long been available, they tend to be either very expensive or very complicated.

Because of this, VB6 developers typically use the free zLib compression library (http://zlib.net/). zLib is an open-source compression library with a very permissive license, and it is "good enough" for most tasks: decent compression ratios, but relatively slow performance.

Unfortunately, in recent years, zLib has lost some of its luster. The stdcall variant of zLib hasn't been updated in over a decade, meaning it contains serious security vulnerabilities. You can always compile your own version of zLib from the latest source code, but the core library definitions are bugged, so this requires C experience and a lot of patience. (Also, zLib's source code is infrequently updated, and there are a large number of bug fixes that have yet to be incorporated.)

And even if you do manage to survive all this and successfully build an up-to-date version of zLib, you're still left with compression technology that is now 20+ years old. Compression technology has advanced greatly since 1995 (when zLib first released), and we now have open-source libraries that outperform zLib in every way.

This project aims to make those libraries available to VB6 developers. It provides a "Compression" module that wraps five different open-source compression libraries: zLib, zLib-ng, zstd, lz4, and lz4_hc. If you're on Windows 8 or newer, it also wraps the four compression engines provided by the Windows Compression API. All compression/decompression functions are unified so you can simply call the "Compress" function, and pass an enum that specifies which compression engine you want to use. The Compression module takes care of the rest.

To simplify this demo, precompiled DLLs are provided for each 3rd-party library. Because the 3rd-party libraries are all open-source projects (links to code below), I believe these still meet the vbforums requirements for precompiled binaries. You are of course free to compile these yourself, from the latest source code, but you will need a modern copy of Visual Studio, some knowledge of compiling C code, and you must manually modify the project files to build stdcall variants. (Like most libraries, they all default to cdecl.)

The 3rd-party DLLs are all bare C libraries, so they do not need to be registered on target PCs. Simply ship them in a subfolder of your project - for example, this demo project uses a "\Plugins\" subfolder, and the DLLs are loaded at run-time via LoadLibrary.

As for the Windows Compression APIs - they are not redistributable, so you can only use them in programs running on Windows 8, 8.1, or 10. Sorry. :( This project will automatically enable them on compatible systems, so if you don't see them, load the project again on a Windows 8+ PC.

Here is a brief overview of the supported compression libraries, and aside from the Microsoft ones, all are 100% open-source and free to use in personal or commercial projects (with attribution - see the included license files for details).

- zLib is the granddaddy of open-source compression libraries. The version supplied here is v1.2.8, which is slightly out-of-date relative to zLib master, but zLib master has some concerning bug reports that make me leery to recommend it. Despite its age, zLib remains a solid general-purpose compression library, with good compression ratios across a wide variety of data, but slow compression speeds compared to the competition. Generally speaking, there is no longer much reason to use it, unless you specifically need the DEFLATE algorithm it provides (e.g. to work with .gz files).

- zLib-ng is an attempt to create a "next-generation" version of zLib, with an emphasis on improved performance and much-needed code cleanup. zLib-ng has yet to release a "stable" build, so I've simply included the most recent developer build. Unfortunately, most of the zLib-ng improvements have thus far focused on 64-bit builds, so I can't guarantee that you'll see any huge improvements. Feedback welcome if you find workloads where it does especially well.

- zstd (or "zstandard") is a modern replacement for zLib. It was originally developed by Yann Collet, and its ongoing development is now sponsored by Facebook. It is 100% open-source and BSD licensed. zstd is significantly faster than zLib at both compression and decompression, and it also achieves better compression ratios. It provides a "compression level" parameter just like zLib, but with a much wider range, including extremely slow speeds but extremely good compression ratios if you need that sort of thing. For most users, zstd could replace zLib in their existing projects, and they'd immediately get a "free" performance boost from it.

- lz4 is a real-time compression engine that emphasizes performance above all else. It was also developed by Yann Collet, and it is also 100% open-source and BSD licensed. lz4 is so fast that it is now used for OS-level compression (Linux), file system compression (OpenZFS, SquashFS), database compression (MySQL), RAM caching (Emscripten, ZRam), and a whole bunch of video games (Battlefield 4, Black Ops 3, etc). LZ4's speed comes at a trade-off, however - it does not compress as well as zLib or zstd on most data. It also provides an adjustable "compression level" parameter, but instead of providing "slower but better" compression as you increase this value, lz4 provides "faster but worse" compression. It is the best solution when speed is paramount. (For example, lz4 is one of the few algorithms fast enough to provide a performance benefit vs raw uncompressed data when reading/writing to a hard drive.)

- lz4_hc comes "for free" with lz4. It is a "high-compression" variant of lz4, with much better compression ratios but much slower compression speeds. Decompression speed remains the same. It is a great solution for "compress once, decompress many" scenarios. (This is the version that various video game engines use, for example.)

- The Windows Compression API available in Windows 8+ provides four different compression algorithms: MSZIP, XPRESS, XPRESS_HUFF, and LZMS. The pros and cons of each algorithm are described on MSDN.

The included demo project allows you to compare compression speed, decompression speed, and compression ratio across all libraries. A baseline comparison of "no compression" is also provided, which measures timing against bare RtlMoveMemory calls. I've included a UTF-8 XML file for comparison (because it's small enough to fit inside vbforum size limits), but for best results, you should test some of your own files. Just drag-and-drop a file onto the project window to run an automated test across all selected libraries.

Attachment 151519

Checkboxes allow you to toggle various test settings. Large files may take awhile to test. Results can be sorted by various criteria.

At present, the Compression module operates entirely on byte arrays and/or bare pointers (passed using VarPtr()). This makes it trivial to compress source data of any size or type. Specialized functions for Strings or other data types could always be added, but for now, those are left as an exercise to the reader.

Bug reports and feedback welcome, of course. Thank you to everyone who has contributed feedback so far.

Updates:

Code:

---

06 September 2017: Added zlib-ng to the list of compressors
                    Added ability to sort results by various criteria (time, ratio, etc)
                    Updated lz4 and zstd builds
                    Minor bug-fixes and code clean-up
12 December 2016: Fixed text box scroll behavior in test program.
                    (Thank you to Steve Grant for reporting.)
                  Added functions to report each library's default, minimum, and maximum compression settings. 
                  Also updated the test framework to let you test these settings. 
                    (Thank you to Arnoutdv for the suggestion.)
                  Added support for the Windows Compression API, available on Win 8 or newer. 
                    (Thank you to dilettante for the idea.)
11 December 2016: Recompile liblz4.dll to fix issues on old OS versions. 
                    (Thank you to Steve Grant for reporting.)
10 December 2016: Initial release

---

Download here:

Hi Tanner, keep getting the following error:

WARNING! LoadLibrary failed to load lz4. Last DLL error: 126
(FYI, the attempted path was: F:\Compression\Plugins\liblz4.dll)

This was originally in my downloads folder, but I wondered if the path length might be too long so I put it on my 'F:' drive. This is where I keep my current VB projects. I even tried putting in ChDrive & ChDir but it didn't help. Anyway loading of liblz4 is third in the list so I assume the others must be loading ok. Any ideas? - Steve.

Hi Steve. Sorry for the trouble. Err 126 usually means a dependency for the current DLL can't be located. I may need to recompile with different settings.

What version of Windows are you on?

Okay - I've recompiled lz4 with some different settings (/MT instead of /MD for the curious), which should remove a dependency on the latest VS2015 runtime. This runtime is provided automatically by Windows Update, but on systems without the latest updates, you should now be able to run the demo anyway. (Note that the DLL is quite a bit larger due to static linking; no way around this.)

I had to tweak some settings in the .zip file to get it under the 500kb forum limit, so if you're on XP you may need to use a program like 7zip instead of the default Windows Explorer .zip editor to open the new zip. Sorry.

Please let me know if this fixes error 126 for you, Steve.

We also have Compression API now, but I haven't tried playing with it yet.

OK the new dll works, but, as you point out, is much bigger!

Windows 10 Home: ver 1607 build 14393.479.
VB6 Pro SP6.

@Steve: thanks for confirming the fix. I'm on the exact same Windows 10 version, so the required dependencies must be tied to VS 2015 instead of shipping as part of Windows Updates. Ugh. Despite the size increase, I'm glad we recompiled the files to make them more portable.

@dilettante: thanks for the reminder. I'll look at adding the Compression API options to the module. I'd be curious to see how their performance compares to other "industry standards."

@Tanner

I compared the compression rates with the ZSTD library compiled by wqweto and was suprised by low compression rate of ZSTD.
When walking through the code I noticed you don't specify a compression level for ZSTD, giving it -1
For ZStandard the compressionlevel default of -1 gives the lowest compression rates, the same as specifying 0 or 1

I also added a compression level to your sample program giving the following results:

Code:

---

zLib initialized successfully!
zstd initialized successfully!
lz4/lz4_hc initialized successfully!

Results for English XML file:
Engine        |        Compress time        |        Decompress time        |        Compression ratio (higher is better)
------------------------------------------------------------------------------------------------------------------------
Zstd        |        0020,60 ms        |        0001,40 ms        |        87,07%        |        -1
Zstd        |        0003,30 ms        |        0001,30 ms        |        87,07%        |        0
Zstd        |        0003,30 ms        |        0001,30 ms        |        87,07%        |        1
Zstd        |        0003,50 ms        |        0001,40 ms        |        87,18%        |        2
Zstd        |        0004,70 ms        |        0001,40 ms        |        87,61%        |        3
Zstd        |        0003,10 ms        |        0000,80 ms        |        87,62%        |        4
Zstd        |        0009,20 ms        |        0000,70 ms        |        88,46%        |        6
Zstd        |        0009,00 ms        |        0000,70 ms        |        88,83%        |        10
Zstd        |        0012,10 ms        |        0000,70 ms        |        88,92%        |        14
Zstd        |        0064,20 ms        |        0000,70 ms        |        88,78%        |        18
Zstd        |        0199,90 ms        |        0000,80 ms        |        89,49%        |        22

Results for Spanish XML file:
Engine        |        Compress time        |        Decompress time        |        Compression ratio (higher is better)
------------------------------------------------------------------------------------------------------------------------
Zstd        |        0003,70 ms        |        0002,00 ms        |        80,82%        |        -1
Zstd        |        0005,40 ms        |        0002,00 ms        |        80,82%        |        0
Zstd        |        0005,40 ms        |        0002,00 ms        |        80,82%        |        1
Zstd        |        0002,90 ms        |        0001,10 ms        |        81,14%        |        2
Zstd        |        0003,80 ms        |        0001,10 ms        |        81,82%        |        3
Zstd        |        0004,00 ms        |        0001,10 ms        |        81,84%        |        4
Zstd        |        0008,50 ms        |        0001,10 ms        |        83,00%        |        6
Zstd        |        0013,50 ms        |        0001,00 ms        |        83,66%        |        10
Zstd        |        0018,00 ms        |        0001,00 ms        |        83,80%        |        14
Zstd        |        0079,30 ms        |        0001,10 ms        |        83,92%        |        18
Zstd        |        0181,50 ms        |        0001,10 ms        |        84,65%        |        22

Results for Chinese XML file:
Engine        |        Compress time        |        Decompress time        |        Compression ratio (higher is better)
------------------------------------------------------------------------------------------------------------------------
Zstd        |        0002,60 ms        |        0001,50 ms        |        77,04%        |        -1
Zstd        |        0005,30 ms        |        0002,00 ms        |        77,04%        |        0
Zstd        |        0005,30 ms        |        0002,10 ms        |        77,04%        |        1
Zstd        |        0002,80 ms        |        0001,10 ms        |        79,07%        |        2
Zstd        |        0003,80 ms        |        0001,10 ms        |        80,13%        |        3
Zstd        |        0004,10 ms        |        0001,20 ms        |        80,21%        |        4
Zstd        |        0008,40 ms        |        0001,10 ms        |        81,17%        |        6
Zstd        |        0013,00 ms        |        0001,10 ms        |        81,64%        |        10
Zstd        |        0016,60 ms        |        0001,10 ms        |        81,76%        |        14
Zstd        |        0074,40 ms        |        0001,10 ms        |        82,05%        |        18
Zstd        |        0164,10 ms        |        0001,10 ms        |        83,22%        |        22

---

I've updated the project to include support for the Windows Compression API available on Win 8 (or newer). Thank you to dilettante for the idea.

@Arnout DV. Thank you for the comment. I've updated the explanation to note that each compression test runs at its default settings. The output would quickly become enormous if each library were tested at its full range of outputs!

Out of curiosity, do you get much performance difference between this DLL and wqweto's version? zstd is under heavy development so I'm curious if they've been able to further improve its performance (or compression capabilities) since he compiled his version.

Test on an 60MB SQLite DB:

Code:

---

Results for D:\Test\demo.db:
Engine  |    Compress time  | Decompress time  |  Ratio      | Level
------------------------------------------------------------------------------------------------------------------------
Zstd    |    0223,40 ms    |    0100,30 ms    |    89,82%    |    -1
Zstd    |    0223,30 ms    |    0100,30 ms    |    89,82%    |    0
Zstd    |    0224,40 ms    |    0100,50 ms    |    89,82%    |    1
Zstd    |    0237,10 ms    |    0108,50 ms    |    89,68%    |    2
Zstd    |    0285,80 ms    |    0099,60 ms    |    90,29%    |    3
Zstd    |    0285,40 ms    |    0099,50 ms    |    90,31%    |    4
Zstd    |    0888,40 ms    |    0097,80 ms    |    90,77%    |    6
Zstd    |    1576,80 ms    |    0087,90 ms    |    91,40%    |    10
Zstd    |    3606,70 ms    |    0079,80 ms    |    92,06%    |    14
Zstd    |    10177,80 ms    |    0072,90 ms    |    93,40%    |    18
Zstd    |  216581,10 ms    |    0070,20 ms    |    95,38%    |    22


Engine  |    Compress time  | Decompress time  |  Ratio      | Level
------------------------------------------------------------------------------------------------------------------------
None    |    0021,90 ms    |    0022,00 ms    |    00,00%    |    -1
Zlib    |    0689,50 ms    |    0123,50 ms    |    87,56%    |    -1
Lz4    |    0088,10 ms    |    0041,70 ms    |    82,48%    |    -1
Lz4_HC  |    2813,80 ms    |    0033,20 ms    |    88,59%    |    -1

---

wqwet
http://www.vbforums.com/showthread.p...=1#post5090713

I will do some basic comparisons with the DLL compiled by wqweto later!

Thanks, I look forward to it. I feel bad the project didn't accept his patches, but fortunately, they've made it very easy to compile an stdcall version. We just have to deal with name-mangling, but that's not much of a problem since there are only a few function names to fix.

When you said "I was suprised by low compression rate of ZSTD," I was worried something was wrong, but I think it's just a matter of perspective. Looking at your SQLite results, zstd at its *lowest* setting still compresses better than zLib, and it does it 3x faster. With results like that, I'm not surprised they've made the decision to default to the fastest setting available.

I agree, I was worried too.
But for ZLib you set the "default" to 3, not using the fastest either ;)

Comparing both DLLs
http://www.vbforums.com/showthread.p...=1#post5090713

Code:

---

Results for D:\Test\demo.db (size: 63.168.512 bytes) :
Engine  |    Compress time  | Decompress time  |  Ratio      | Level
------------------------------------------------------------------------------------------------------------------------
Zstd    |    3606,70 ms    |    0079,80 ms    |    92,06%    |    14
Zstd    |    10177,80 ms    |    0072,90 ms    |    93,40%    |    18


wqweto:
Zstd    |    3630,02 ms    |    xxxx,xx ms    |    92,06%    |    14
Zstd    |    9763,25 ms    |    xxxx,xx ms    |    93,43%    |    18

---

ps
Up until now I always use Zlib with compression level 6.
Slowly switching to ZSTD with compression level 18, much better compression and also better decompression speed (compression speed not really an issue, but level 22 is very very slow)

Ack, good catch on zLib - their default setting actually resolves to 6, not 3. Not sure how I missed that. I'll update the code to match. The goal was to use the default values specified by the libraries themselves, but I messed that up for zLib...

Actually, given that each library has totally different min/max values, I should probably provide a function to retrieve those, so people don't have to guess. I should also make it obvious where the various "Default" levels actually resolve to. Add this to the to-do list! :)

It looks like there have been some adjustments to what the specific Zstd compression levels mean since wqweto's patch. I know this is a constant source of discussion (e.g. this patch just updated things last week: https://github.com/facebook/zstd/issues/466). That might be good to know as new releases may necessitate revisiting any hard-coded compression levels.

Thanks much for the info and ideas. I'll update the code in the next few hours to make things like compression level more transparent.

The LZ4_HC compression level is by default on almost best compression.
For better compression speed and slightly worse compression rate specify 1..8
For hardly any better compression but increased compression time 10..16

Code:

---

lz4/lz4_hc initialized successfully!
Results for D:\demo.db:
Engine        |        Compress time        |        Decompress time        |        Compression ratio (higher is better)
------------------------------------------------------------------------------------------------------------------------
None        |        0022,10 ms        |        0021,90 ms        |        00,00%        |        -1
Zlib        |        1609,30 ms        |        0126,20 ms        |        89,18%        |        6
Zstd        |        10158,30 ms        |        0072,80 ms        |        93,40%        |        18
Lz4        |        0088,70 ms        |        0042,90 ms        |        82,48%        |        -1
Lz4_HC        |        2850,80 ms        |        0033,50 ms        |        88,59%        |        -1
Lz4_HC        |        0334,30 ms        |        0038,60 ms        |        84,78%        |        1
Lz4_HC        |        0389,70 ms        |        0037,40 ms        |        85,82%        |        2
Lz4_HC        |        0482,80 ms        |        0035,90 ms        |        86,66%        |        3
Lz4_HC        |        0609,90 ms        |        0034,80 ms        |        87,31%        |        4
Lz4_HC        |        0803,20 ms        |        0034,10 ms        |        87,79%        |        5
Lz4_HC        |        1106,80 ms        |        0033,70 ms        |        88,14%        |        6
Lz4_HC        |        1554,50 ms        |        0033,50 ms        |        88,38%        |        7
Lz4_HC        |        2168,70 ms        |        0033,80 ms        |        88,52%        |        8
Lz4_HC        |        2823,40 ms        |        0033,50 ms        |        88,59%        |        9
Lz4_HC        |        3459,20 ms        |        0033,30 ms        |        88,61%        |        10
Lz4_HC        |        4247,30 ms        |        0033,30 ms        |        88,63%        |        11
Lz4_HC        |        5378,50 ms        |        0033,50 ms        |        88,64%        |        12
Lz4_HC        |        7422,90 ms        |        0033,00 ms        |        88,65%        |        13
Lz4_HC        |        10758,90 ms        |        0033,00 ms        |        88,66%        |        14
Lz4_HC        |        14638,50 ms        |        0033,40 ms        |        88,67%        |        15
Lz4_HC        |        21852,70 ms        |        0033,30 ms        |        88,67%        |        16

---

Okay, I've now added functions that report the default, minimum, and maximum settings for each compression library. Note that these do nothing for the Windows Compression API functions, because they don't support variable compression levels. (Well, that's not *entirely* true - XPRESS and XPRESS_HUFF support levels of "0" or "1", but I haven't implemented these as their usefulness seems... dubious?)

I've also fixed the zLib definition to default to the correct value - thanks @Arnoutdv for catching!

I've also added some checkboxes to the UI to give more control over the test parameters. Automated tests of each library's minimum, maximum, and "middle" values are now available, which is helpful for seeing the range of results each library might provide. Just be forewarned that the test may take awhile on very large files.

Thanks again to everyone for their help and feedback.

This is a daft one! When I try to scroll the textbox, the textbox itself moves whilst the mouse is down. When I let go it springs back to its original position. At no time can I actually scroll the textbox!!!

@Steve - apologies, that was (another!) dumb mistake on my part. At some point I must have accidentally toggled the regular "DragMode" property instead of the "OLEDragMode" property. Just change the text box's "DragMode" property to "0 - Manual" and it will behave normally.

I'll get that changed in the master copy as well...

Good work. I have a dumb question for you. The compression and decompression algorithms all work on data that is in memory which is fine but how do we store the compressed files in a zip file type on disk? I looked in the ZStd documentation on GitHub and couldn't find anything that described DLL calls to fetch header information for filenames, paths, etc. so I am not sure how to take what you (and they) have done and make a set of routines that can read/write compressed data for one or more files to/from a disk that can be read/written by other programs that deal with the zip format. Where do I find this information? Thanks.

The ZlibWapi DLL can be used for creating and extracting ZIP archives.
Samples in the Codebank:
VB6 - Zipper & ZipWriter, Zipping from VB programs

Or without external DLL:
[VB6] Create a ZIP file without any DLL depends using IStorage and IDropTarget

I had occasion to revisit this project recently, so I've placed the source on GitHub and added a few improvements.

• zLib-ng is now supported. This is a "next-generation" version of zLib focused on performance improvements. To be honest, I've yet to see meaningful improvements over stock zLib, but maybe I just haven't tested the right workloads...?
• lz4 and zstd have been updated to their latest builds. zstd in particular should be both faster, and capable of better compression ratios.
• The sample project now lets you sort the output by compression/decompression time, compression ratio, and compression ratio vs time taken. This should make it much more useful for comparing various engines.
• I also fixed a few minor bugs; if you can, upgrading to this newest version is recommended.

I'm bumping up tightly against forum attachment size limits (and I had to cut the "test files" folder down to a single test file to upload it at all), so going forward, minor patches/improvements may only get posted to GitHub. I'll still try to post comments here for any major changes, or if I decide to add any other compression libraries to the collection. (Suggestions welcome!)

you can do what Krool does and a .docx extension to get around the size limits. (actually someone just got a warning in another thread for doing this, maybe you need special permission from the mods)
Also great project. My only suggestion is to use a common interface and group the plugins into class modules. It would get rid of a lot of boiler plate select case, but I'm just being superficial.

Thanks Tanner for the updates!

@DEX - Thanks for the great suggestion. I wish I'd done that in the first place. :/ Oh well, better late than never!

The GitHub copy has now been updated so that each compression library uses its own class module, and each class module implements a uniform ICompress interface. This does indeed simplify the code, and it means you don't need the Compression module at all. Just grab the class file for the compression engine you want, and the ICompress interface, and you're good to go. (I've also placed the various Windows compression formats into their own class files, so they're much easier to use now, too.)

Unfortunately, no combination of black magic can get the new .zip file under the damn forum size limit (AAAARRRGGGHHHH 500KB IN 2017 IS RIDICULOUS), so you'll have to go to GitHub to grab the newest version. Apologies, but there's nothing I can do, and if mods are removing "workarounds" from other threads, I'm not going to waste time fighting it.

@Arnoutdv - you are very welcome!

That was fast, and it really cleaned up Compression.bas :thumb:

Hi Tanner,
Thank you for this project and for all details. These comparisons are very useful for sure but how could we use these libraries in some specific situations? I would like to see a sample with a few files that are compressed and decompressed. Did you exposed in your plugins all functions of these libraries or there are other functions involved in saving the compressed files as a archive?

Hi Daniel. The 3rd-party libraries used in this project do not deal with archives at all. Archiving and compression are separate problems. These libraries only tackle the compression part.

This can be confusing, even with popular libraries like zLib. To use it as an example, the zLib library can produce individual compressed .gz streams, but you need a separate tool to combine multiple .gz streams into a single tar.gz archive. To handle zip files, some developers bundle an archive library called "minizip" together with zlib, so they can handle compression and archiving together - but the "minizip" archive project is totally different from the "zLib" compression project. ZLib just performs compression and decompression of raw byte streams.

So just like zlib, this sample VB6 project will only help you compress and decompress raw data. Zip files are a different problem. (Zip files wouldn't work with the modern compression libraries used here, anyway.)

If you need VB6 sample code based on creating compressed .zip archives, I very much like wqweto's solution. There are a number of other .zip file solutions in the forums - I think Arnoutdv shared some additional links above.

Hope that helps!

Quote:

---

Originally Posted by Tanner_H

Zip files wouldn't work with the modern compression libraries used here, anyway.

---

It is a bit strange because even in this section of the forum Dilletante published a Zipper using the zlibwapi.dll library (http://www.vbforums.com/showthread.php?720251). Perhaps your project is dedicated to compression exclusively, however so far I thought that any archiving process involves a compression. I have to recognize that until now I didn't use files compression in my apps and would be useful to know some practical advantages of this process. I suppose that one benefit is the file size decreasing but could be transferred such a compressed file using a mail ? Thank you.

Archiving can use compression, compression is not archiving.
Indeed in the code library are multiple solutions to work with ZIP files directly from within VB6.

Regarding your email question, can you explain what you want to do?
If I send data files to a client I always ZIP it. Hardly ever I send an original file.
Reason 1: compression; makes the actual attachment smaller
Reason 2: encryption; a ZIP file can be password protected

Compression is not archiving but almost any archival tool makes compression. I mean, besides collecting multiple files together into a single file for easier storage or transfer each archive usually contains a compressing component. The question is: could all these libraries be components of an archiving tool ? Regarding files transfer via email I am not interested in encryption because my files usually contain numbers (that are not easy to understand even for a specialist :)) but of course the size is important considering the attachment size limitations. Personally, I archive files when I have over two or when they exceed 10Mb in size. But returning to the compressing benefit, I wondered if it is possible to attach a compressed file and sending it to a customer that has possibility to decompress it properly. Finally, it would be useful to know what other uses has compression itself. Thank you all.

Quote:

---

I wondered if it is possible to attach a compressed file and sending it to a customer that has possibility to decompress it properly.

---

If you use a general accepted compression format/container then this is no problem
Therefor most often files are compressed using the ZIP format (You can use WinZIP, WinRAR or the free 7Zip for this)

Quote:

---

Originally Posted by Daniel Duta

Finally, it would be useful to know what other uses has compression itself. Thank you all.

---

There are many times when it is valuable to compress data, but you don't want or need other people to access it.

For example, I use these compression libraries to compress all Undo/Redo data generated by my programs. In the case of PhotoDemon, for example, Undo/Redo data can be enormous (one action on an iPhone photo can be ~50 mb uncompressed), but compression shrinks that size significantly. This means a much smaller impact on the user's HDD, and many more Undo actions before running out of space.

I also heavily use compression to reduce program RAM usage. When I need to keep large objects in memory, I leave them compressed, and decompress only the parts I need, and only when I need them. This lets the program maintain a tiny footprint, without incurring performance penalties by constantly needing to load data from disk.

Many of my clients have software that uses its own custom file formats. Writing these files in an uncompressed format means they are huge, sometimes hundreds of MBs each. Compression from the libraries in this project can reduce that number by 80-90% or more. (In the case of biological data, like DNA sequencing results, compression can reliably reduce file sizes by 98+%.)

For more examples, you can check out the homepage of any of these compression libraries. LZ4 alone lists hundreds of familiar software packages that employ it in a huge variety of ways.

If you really want to mix archiving capabilities with these compression libraries, it is trivial to create your own archival format. A simple archive format is just a table of offsets, one per original file, plus a little bit of extra metadata (like each file's original size and name). I do something like that here, for example. By using my own simple archive format instead of zip files, I get archives that are 1) much faster to read/write, and 2) much smaller than a corresponding zip archive.

Similarly, zip archives are a good choice if you want something that anyone can read and modify, but there is often a need for archival formats that are *not* easy to read or modify. For example, when you ship software, if you keep all your program data in zip files, any user (or malware, etc) can freely modify those files, or extract data or information that you may not want them to extract. A non-zip archive prevents this. (Or at least, makes it more difficult for them.)

Most of this is covered in Wikipedia's data compression article, but maybe it will be helpful here, too. ;)

https://mcmilk.de/projects/7-Zip-zstd (or https://github.com/mcmilk/7-Zip-zstd)

This project uses 7-zip as a container to implement zstd, brotli, LZ4 and other compression "codecs" (or methods as shown in the UI).

cheers,
</wqw>