Testing zlib compression in Delphi

[dummzeuch 1392]

Delphi has for a while contained two classes that simplify stream compression:

• TZCompressionStream
• TZDecompressionStream

I had not used them before and when I tried to use them now to compress and decompress some binary data that is stored as part of a large file, I got some inexplicable results. So I wrote this little test program to find the problem.

 

Read on in the blog post.

[David Schwartz 415]

It has been a while since I used these, but they work as intended. They let you compress and decompress a string or chunk of data in memory or a stream. It's not a "zip file" with a directory b/c ... what would it put in the directory if. say, there were 30 strings you were compressing? It takes a chunk of data and either compresses it or decompresses it. If you don't know the length of the uncompressed data, then it needs to figure it out. But chances are it's either quite small (ie, the overhead needed to figure it out is minimal) or you're going to save uncompressed size in your data record along with the compressed data so you know how much data it's going to take when it's uncompressed.

 

Maybe think of it the same way as encoding and decoding data to/from Base64, only in that case the sizes are easy to calculate.

 

I don't find any of this puzzling. Including the reference to ChangeFileExt -- although when I started using it (going back to DOS days), I thought it was odd that it assumed the dot '.' was part of the extension. But over time, it makes more sense that way so you can say ChangeFileExt( fn, '' ) to remove it AND the dot to get the BaseName that doesn't include the dot either. Coming from the c / Unix world, extensions are superflous, like in Macs (which are Unix-based), so it was weird to me that DOS (and later Windows) depended upon them to identify file types. In Unix, everything has some kind of file header in it, and there's even a command (file <filename>) that does a really good job of figuring out what type of file something is by reading a chunk of bytes from the beginning of the file. I think *nix allows file extensions simply as a courtesy to DOS / Windows, but doesn't hold them as having any significance. When I first started working with Unix in the mid-80s, file names rarely had extensions on them as they simply weren't needed. However, things that transformed an input file to a different format output file did tend to use an extension, so a C source file had a .c extension; the output of the cpp command (rarely used to save files) used a .cpp extension; the output of the c compiler used a .o extension. But the output of the linker used no extension. In fact, just typing a filename on the command line would run it using whatever it needed: it could run as an executable, or via sh, bash, ksh, csh, etc, if it was a shell script; and so on. Unix just figured it out, and totally ignored any extension that might be present. AFAIK, Linux systems still do that today. I suppose it just depends on your background? DOS and Windows still have a lot of vestiges hanging around from their Unix roots. (I just never figured out why DOS used backslashes instead of forward slashes in file paths, other than simply to look different. In Unix, backslashes are used universally as an escape character. Also, single and double quotes (' vs. ") are interpreted differently in a lot of contexts, unlike in DOS and Windows where they're typically equivalent.)

 

 

Edited July 31, 2023 by David Schwartz