Zlib package for Lazarus 3.6?

[dpap]

I am porting my app from Delphi to Lazarus but I need the compression/decompression functions that I used in Delphi with Zlibx.
Is there the analog package for Lazarus 3.6?

[BSaidus]

Yes, check in the fpc/units/i386-win32/zlib/ and \fpc\sources\packages\zlib\ for source.
You can use the one that comes with delphi, with some modifs

[dpap]

I Tried with modifications of Delphi unit but failed. In my FPC installation dir I found only 3 files for i386 (Zlib.fpm, zlib.o, zlib.ppu).
How can I use them?

[TRon]

How can I use them?

Code: Pascal  [Select][+][-]

1. uses zlib, ...;

see also https://www.freepascal.org/daily/packages/zlib/zlib/index-5.html

[marcov]

zlib is a header for an external zlib (mostly on *nix).

However a translation of zlib to Pascal, paszlib is most commonly used, as it has no extra dependencies

[dpap]

I modified Delphi's ZlibX  adding "@" before zlibAllocMem and  zlibFreeMem  and I put it (and all obj files) in app's directory but when I build the app I receive the error "Error: Illegal COFF Magic while reading trees.obj".
What can I do to work properly, please?
PS. I am new in Lazarus world

[cdbc]

Hi
To reiterate @marcov:
<quote>
However a translation of zlib to Pascal, "paszlib" is most commonly used, as it has no extra dependencies
</quote>
Use 'paszlib' and adjust your calling code accordingly...!
Regards Benny

[dbannon]

Just to clarify a touch dpap, both zlib (bindings to a library) and paszlib are included with FPC.  When you found just Zlib.fpm, zlib.o, zlib.ppu you were looking in the FPC binary tree. If you look in <FPC-SRC>/packages/paszlib and <FPC-SRC>/packages/zlib you will find a bit more, source code, examples etc.

There is also (in paszlib) zipper, an OO wrapper around paszlib, I use it.

Davo

[dpap]

I found the units Zlib and PasZlib and I tried them.
Zlib makes a minimal sample app to crash immediately (before the Begin of the app)
PasZlib seems to work. I wrote a minimal code that executes but with problem.
the sample code :
procedure TForm1.Button1Click(Sender : TObject);
var
  sourcePchar : PChar;
  destPchar : Pchar;
  destLen : cardinal;

begin
   sourcePchar := '01234wretyr ywrtyery eryιοηιοπηεςγ ςερρτγπιοξσδφγ σδγποξσδγδγη φδσγηποδσφη χψβνπ]ο σδηγόξσδητ wry weytwrwy wreywrt wertwet wettw wertwet wety567890';
  destLen := length(sourcePchar);
  showmessage(inttostr(destLen)); // shows 210
  compress(@destPchar,destLen,@sourcePchar,length(sourcePchar));
  showmessage(inttostr(destLen)); //shows 168
end;
on exiting throws the error "External ACCESS VIOLATION... reading from address $13A67AEA"

what is my fault, please ?

[cdbc]

Hi

sourcePchar := '01234wretyr ywrtyery eryιοηιοπηεςγ ςερρτγπιοξσδφγ σδγποξσδγδγη φδσγηποδσφη χψβνπ]ο σδηγόξσδητ wry weytwrwy wreywrt wertwet wettw wertwet wety567890';

The above, is NOT how the piano plays... You have absolutely *no* memory-allocation before you stuff the 'SourcePchar' full of chars....
When you use pchars, YOU have to do it all, mem-allocation, mem-length, mem-realloc & mem-free...!
That's why it blows up with an AV.
Regards Benny

[ASerge]

Example:

Code: Pascal  [Select][+][-]

1. uses ZCompres, ZUncompr;
2.  
3. { TForm1 }
4.  
5. procedure TForm1.Button1Click(Sender: TObject);
6. const
7.   CSomeData = '01234wretyr ywrtyery eryιοηιοπηεςγ ςερρτγπιοξσδφγ σδγποξσδγδγη φδσγηποδσφη χψβνπ]ο σδηγόξσδητ wry weytwrwy wreywrt wertwet wettw wertwet wety567890';
8. var
9.   PackedData, UnpackedData: TBytes;
10.   PackedDataLen, UnpackedDataLen: Cardinal;
11. begin
12.   UnpackedDataLen := Length(CSomeData);
13.   PackedDataLen := Round(UnpackedDataLen * 1.1) + 12;
14.   Memo1.Text := Format('Source length: %d, Dest buf length: %d', [UnpackedDataLen, PackedDataLen]);
15.   SetLength(PackedData, PackedDataLen);
16.   if compress(Pointer(PackedData), PackedDataLen, PByteArray(PAnsiChar(CSomeData))^, UnpackedDataLen) = 0 then
17.   begin
18.     Memo1.Append(Format('Compress size: %d', [PackedDataLen]));
19.     SetLength(UnpackedData, UnpackedDataLen);
20.     if uncompress(Pointer(UnpackedData), UnpackedDataLen, PByteArray(PackedData)^, PackedDataLen) = 0 then
21.     begin
22.       Memo1.Append(Format('Decompress size: %d', [UnPackedDataLen]));
23.       Memo1.Append('DATA:');
24.       SetLength(UnpackedData, UnpackedDataLen);
25.       Memo1.Append(UTF8Encode(UTF8ToString(UnpackedData)));
26.     end;
27.   end;
28. end;

[Khrys]

Hi

sourcePchar := '01234wretyr ywrtyery eryιοηιοπηεςγ ςερρτγπιοξσδφγ σδγποξσδγδγη φδσγηποδσφη χψβνπ]ο σδηγόξσδητ wry weytwrwy wreywrt wertwet wettw wertwet wety567890';

The above, is NOT how the piano plays... You have absolutely *no* memory-allocation before you stuff the 'SourcePchar' full of chars....
When you use pchars, YOU have to do it all, mem-allocation, mem-length, mem-realloc & mem-free...!
That's why it blows up with an AV.
Regards Benny

No, this is perfectly fine (as long as the data is only read). The string data is embedded in a read-only section of the binary (.rodata  or  .rdata) and the  PChar  variable receives its address.
Even C, notorious for its lack of a real string type, can embed string data this way. The real pitfall lies with attempting to modificy that data:

Code: C  [Select][+][-]

1. char *msg = "hells world";
2. msg[4] = 'o'; // Access violation - attempting to write to read-only memory

With that being said, this is more of an exception to the general rule that working with  PChar  requires attentive manual memory management. But that's not the only issue here:

Code: Pascal  [Select][+][-]

1. function compress (dest : Pbyte;
2.                    var destLen : cardinal;
3.                    const source : array of Byte;
4.                    sourceLen : cardinal) : integer;

Code: Pascal  [Select][+][-]

1. compress(@destPchar,destLen,@sourcePchar,length(sourcePchar));

The first argument is a  PByte,  but you're passing a  PPChar  (pointer to pointer to char) because you're superfluously taking the pointer's address; leave out the  @  and allocate some memory, e.g. with  destPchar := GetMem(Round(sourceLen * 1.001 + 0.5) + 12).
The third argument is an open array of Byte (which IMO is superfluous when an explicit length parameter exists and makes everything less intuitive). In this case you should get away with reinterpret-casting the source data as such an array with  PByteArray(sourcePChar)^  since the underlying function doesn't use  Length(source) (which would contain garbage).

[dpap]

Zlib finally worked