Attached is LZ-77 implementation.
Posted on 2002-07-18 00:35:18 by comrade
Good contribution comrade. ;)
Posted on 2002-07-18 03:33:24 by Maverick
Yep,

This is a good piece of code that works well, I have downloaded it and tested it and it works fine.

Regards,

hutch@movsd.com
Posted on 2002-07-29 21:24:48 by hutch--
Great piece of code comrade,

I was just wondering about the patents on the limpel - ziv algorithm , if this was ever used in a commercial application, wouldnt there be a problem?
Posted on 2002-07-30 04:13:25 by Terab
Sorry to say, but I got a bug with a file...


C:\>pack d:\output\top\topfr.zip c:\tst.l77
LZ77 Packer
Built on 07/18/02 01:30:44
Version 1.0
Coded by comrade <comrade2k@hotmail.com>
Web: http://euro.comrade64.com/
http://comrade64.cjb.net/
http://comrade.ownz.com/
http://comrade.win32asm.com/
http://comrade.hpacv.dk/
http://www.comrade64.com/
IRC: #asm, #coders, #win32asm on EFnet

Error at 004011ECh
Registers:
eax = 1FFFFFFFh ebx = 10020020h ecx = 0012FFBCh
edx = 00130608h esp = 0012FF7Ch ebp = 0012FF9Ch
esi = 00000000h edi = 3002001Fh
Recovering...


But it really works well with most files!
Posted on 2002-07-30 07:09:49 by JCP
Really nice and fast!



C:\temp\Lz77>pack test.dxf test.out
LZ77 Packer
Built on 07/18/02 01:30:44
Version 1.0
Coded by comrade <comrade2k@hotmail.com>
Web: [url]http://euro.comrade64.com/[/url]
[url]http://comrade64.cjb.net/[/url]
[url]http://comrade.ownz.com/[/url]
[url]http://comrade.win32asm.com/[/url]
[url]http://comrade.hpacv.dk/[/url]
[url]http://www.comrade64.com/[/url]
IRC: #asm, #coders, #win32asm on EFnet

C:\temp\Lz77>dir test.*
Datentr?ger in Laufwerk C: hat keine Bezeichnung.
Datentr?gernummer: 08AD-42A2

Verzeichnis von C:\temp\Lz77

22.04.2002 13:14 59.145.568 test.dxf
30.07.2002 14:15 6.608.469 test.out
2 Datei(en) 65.754.037 Bytes
0 Verzeichnis(se), 30.325.571.584 Bytes frei

C:\temp\Lz77>


AutoCAD produces such bloated files :)
Posted on 2002-07-30 07:16:25 by bazik
Perhaps readiosyses bug is a problem with the memory allocation in case of incompressible
data?

Also comrade, why use GlobalAlloc instead of HeapAlloc? *nag* *nag*
Posted on 2002-07-30 07:52:50 by f0dder
because HeapAlloc limits how much you can allocate, or atleast on my windows xp.
Posted on 2002-07-30 11:12:38 by Qages
Thats impossible, because Local/GlobalAlloc call HeapAlloc internally :)
Posted on 2002-07-30 11:32:21 by bazik
one time i HeapAlloc over a megabyte, it crashed, but when i changed the code to globalalloc it didnt crash. ... i tried it 2 times it crashed with HeapAlloc , but not with global, hummmph
Posted on 2002-07-30 11:35:35 by Qages
perhaps you've run the HeapAlloc (very) shortly after allocating a *huge*
amount of memory? I can probably get away with allocating a 512meg
chunk (or at least a 256meg chunk), but not twice in a row - and not
immediately after freeing the other one (windows will have to do some
cleanup stuff first, which isn't done *exactly* at the memory free calls -
whether you're using Global/Local* or Heap*). Also, was this on NT or 9x?
On NT, Global/LocalAlloc go very quickly to HeapAlloc after some parameter
conversion (and HeapAlloc is forwarded by kernel32 to NTDLL:RtlAllocateHeap
or similar). On 9x it's somewhat different, and I haven't yet studied the
details clearly.
Posted on 2002-07-30 11:40:23 by f0dder
im windows xp. i just allocated it and it crashed with heap, i dunno, so i always use global
Posted on 2002-07-30 11:43:26 by Qages
Show a sample of a crashing HeapAlloc call, please.
Posted on 2002-07-30 11:48:50 by f0dder
i dont remember what program it did it on, but i remember it did crash with heapalloc.
Posted on 2002-07-30 11:58:24 by Qages
Readiosys, could you e-mail those files to me please? I am also on IRC #win32asm EFnet, so you can DCC Send them as well.
As I can see from the crash info, esi is 0, so it was unable to allocate the required memory. It can be because the file size is too large, or is 0, or it could not open the input file.
Posted on 2002-07-30 12:54:20 by comrade
Sorry !
It was all my fault there...
Somebody deleted a file I presumed to be there... I put it on the right place and all went ok...

But there is a problem though... if the input file doesn't exist (or can't be opened), it crashes...
After a quick look to the code, you don't seem to check the CreateFile return value to know if the file was sucessfully opened...



invoke CreateFile, [argv+04h], GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0
mov [hFileIn], eax
invoke CreateFileMapping, eax, 0, PAGE_READONLY, 0, 0, 0
mov [hFileMapIn], eax
invoke MapViewOfFile, eax, FILE_MAP_READ, 0, 0, 0
mov [dwFileIn], eax
invoke GetFileSize, [hFileIn], 0
mov [dwUnpackedSize], eax


The error wasn't very explicit about this missing file... so I didn't even bothered to check if it was at the right place...
I prefer this, as it is not a problem to the compression code and will avoid you debugging pain, but it deserves a little fix in the public version, imho. ;)
Posted on 2002-07-30 13:35:37 by JCP

i dont remember what program it did it on, but i remember it did crash with heapalloc

And from that very detailed information you assume HeapAlloc is inferior to Global/LocalAlloc? :tongue:
Posted on 2002-07-30 15:34:55 by f0dder