I am implementing a feature that requires zlib compression/decompression on a Windows CE platform supporting C#/.NET. This is an old system and I'm struggling to get zlib deflate()/inflate() to work. I started with zlib version 1.2.3 (which is already built and linked) but I also updated it to version 1.2.11. Both versions exhibit the same issue.
The C# managed code pInvokes
zlib.compress (cBuf, cBufSize, "This is the content.", 20)
and it returns
cBufSize = 15
cBuf = {0x0b, 0x61, 0xc8, 0x60, 0xc8, 0x64, 0x28, 0x66, 0x50, 0x80, 0x92, 0x25, 0x40, 0x3e, 0x00}
My C# managed code then pInvokes
zlib.uncompress(tBuf, tBufSize, cBuf, 15)
and it returns
tBufSize = 20
tBuf = {'T','h','i','s',' ','i','s',' ','t','h',0,0,0,0,0,0,0,0,0,0}
For some reason only half the original byte stream is being compressed (or decompressed). This is true for all the attempts I made to vary the original data stream. The second half of the tBuf is always zeros!
Since I don't know anything about how zlib works, I have not tried to debug it. I'm hoping someone has an idea what might be wrong with the zlib configuration on this very old Windows CE platform.
The compressed data in cbuf is complete and correct raw deflate data. It decompresses to (in hex):
54 00 68 00 69 00 73 00 20 00 69 00 73 00 20 00 74 00 68 00
What you see are zero bytes in between each of the characters. You are in fact getting 20 bytes back. The problem is that the 20 bytes you provided to zlib to compress are just the first ten characters of your string, which are apparently encoded as two bytes each.
I don't know much about C# or Windows systems, but I would guess that your character string is being stored as UTF-16 for some reason.