Hi everybody What I want to do is to write some kind of self-extracting setup (single executable). This setup should be able to either decompress a rar zip or ace archieve. I could do this using e.g. the free rar dll But then I would have a dll I must deliver with my setup and I don't want this. Is there any chance of creating a decompression tool which doesn't need to have a dll. I has to be a single executable. If anybody can help me with this I would be glad, to hear it. thx. sign CyBerian
Posted on 2001-02-22 13:00:00 by CyBerian
Take a peek at JCALG1 r5.23 by Jeremy Collake. He's told me he wrangles some of the earlier bugs out of it, and the decompressor asm source code he provides compiles to under 300 bytes. And it's very fast decompressing. Compression is a tad slow, but YOU only have to do it once while compiling the program resources. It's free if you include About box credit. Collake Software
Posted on 2001-02-22 13:15:00 by Ernie
thx. I will take a look. Anyway something like Ace compression would be better for my needs. If anybody knows a way to do something like this in a single executable tell me please sign CyBerian
Posted on 2001-02-22 14:28:00 by CyBerian
CyBerian, I realize you not looking for any extra .DLL as you indicated, but i downloaded the source (just after hacking out my resouce experiments with RCDATA posted earlier) and can easily see how 1 and 1 can come together... 1. use the compresion tool that comes with it (save coding) save as .tst files 2. resouce all your .tst files ( File1 RCDATA first.tst etc.) 3. compile the resouce and link the .res with the static lib given to your final exe (basically following the example in the .cpp file.) 4. use the code i suggested in my post to get the RC data with an extra invoke SizeOfResource to load the resource (from you exe, no the dll as i was playing with) Im quite impressed here, im making this my next topic for experimentation.. :) I think i should have it working in about 2 hrs tops.. (famous last words heheh) NaN
Posted on 2001-02-22 23:37:00 by NaN
CyBerian, have a look at Jibz's aPLib in the MASM32 example code, it tests up a bit better than pkzip and it is typical of LZ style compression, reasonably fast and decompresses very fast. It occurs in the form of libraries that you can include directly in your MASM executable and it is reasonably straight forward to use. If you are going to use it commercially, you can buy a release version from Jibz but apart from that, its licenced to use with MASM32. Regards, hutch@pbq.com.au
Posted on 2001-02-23 00:46:00 by hutch--
Success and 1/2 hr shy of expectations.. :) It was less effort then expected. The MASM static lib was given as well as the PROTO's.inc. so i just added it to a project. My version works as one stand-alown exe RESOURCE CODE:

500 ICON MOVEABLE PURE LOADONCALL DISCARDABLE "MAINICON.ICO"

MOSTUFF RCDATA dialog.tst  /* this is the compressed data */

600	MENUEX MOVEABLE IMPURE LOADONCALL DISCARDABLE
BEGIN
    POPUP "&File", , , 0
    BEGIN
        MENUITEM "&Open", 1000
        MENUITEM "", , 0x0800 /*MFT_SEPARATOR*/
        MENUITEM "&Decompress", 1001
        MENUITEM "", , 0x0800 /*MFT_SEPARATOR*/
        MENUITEM "&Exit", 1010
    END
    POPUP "&Help", , , 0
    BEGIN
        MENUITEM "&About", 1900
    END
END
Extra Includes (Thanx to Jeremy Collake for his hard work)

      include \MASM32\INCLUDE\jcalg1_proto.inc

      includelib \MASM32\LIB\jcalg1_static.lib
And the SaveFile Addin's

     invoke FillBuffer,ADDR szFileName,length szFileName,0
     invoke SaveFileName,hWin,ADDR szTitleS,ADDR szFilterS
    
     cmp szFileName[0],0   ;<< zero if cancel pressed in dlgbox
     je @F

     invoke GetModuleHandle, NULL
     mov hMod, eax
          
     szText rsrcName2, "MOSTUFF"
     invoke FindResource, hMod, addr rsrcName2, RT_RCDATA
     mov hData, eax
     invoke LoadResource, hMod, eax
     mov lpData, eax
     invoke SizeofResource, hMod, hData
     mov lsize, eax
            
     invoke JCALG1_GetUncompressedSizeOfCompressedBlock, lpData
            mov ucsize, eax
     DPrintValD eax, "Uncompressed Size"  ; Ernie's DMacros
     mov ebx, ucsize
     add ebx, 1000
     DPrintValD ebx, "Uncompressed Size + 1000"

     invoke GlobalAlloc, GMEM_MOVEABLE or GMEM_ZEROINIT, ebx
     mov hMem, eax
     invoke GlobalLock, hMem
     mov lpBuffer, eax

     ; --- ACTUAL DECOMPRESION HERE ---           
     ;nFilesize=JCALG1_Decompress_Fast((void *)pData,pBuffer);
     invoke  JCALG1_Decompress_Fast, lpData, lpBuffer
     mov lsize, eax

     invoke CreateFile, ADDR szFileName,
                       GENERIC_WRITE, \
                       NULL, \
                       NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL,\
                       NULL
          
     mov hFile, eax
           
     mov ebx, lsize
     ;WriteFile(hOutputFile,pBuffer,nFilesize,&nBytesRead,0);
     invoke WriteFile, hFile,lpBuffer,ebx, ADDR lsize, NULL
     mov ebx, lsize
     DPrintValD ebx, "Size Written" 
        
     invoke GlobalUnlock, lpBuffer
     invoke GlobalFree, hMem
     invoke CloseHandle, hFile

     @@:
     ...
I didnt realize there was an example in MASM as well, i will have to play with that as well :) CyBerian, if this is what your looking for, the cost of a message in the about box is not too expensive at all... NaN
Posted on 2001-02-23 01:25:00 by NaN
I have 1 curiosity as an outcome of this little experiment.. The Test program was written in C++ and the filesize integer was was defined as and unsigned int. This implies a limitation per to a max size of ~64K. How would you deal with an uncompressed file size larger than this?? ( touches base on dealing with integers > DWORD ) How would you deal with a compressed file size larger than this packed in the exe itself? NaN
Posted on 2001-02-23 01:45:00 by NaN
NaN, If my memory serves me correctly, a UINT in C is a 32 bit unsigned integer which is a DWORD in assembler. I know for sure that Jeremy's compressor as well as Jibz's handle much larger than 64k so you should have no problem there. Regards, hutch@pbq.com.au
Posted on 2001-02-23 02:11:00 by hutch--
There's C source code available for UnRar. This means you can modify it exactly to your own needs. You don't have to include a DLL or anything, and you could include your data in the resource section to avoid more than a single exe file. Sure, rewriting the unrar code will be hard work, but...then you can use winrar to make your archives, rather than having to code up a custom one based on aPLib or jcalg.
Posted on 2001-02-23 03:26:00 by f0dder
That's sounds very nice to me. Do you know where to get the proper C Source? I can't find it anywhere on the net sign CyBerian
Posted on 2001-02-23 08:18:00 by CyBerian
I found it at the official rar site - http://www.rarsoft.com. I think it should still be there?
Posted on 2001-02-23 09:16:00 by f0dder
ohh.. I will take a look there thx. But after I tested some things with the Jcalg Compression. I think it could be the right one. Especially because of the real fast decompression sign CyBerian
Posted on 2001-02-23 10:31:00 by CyBerian
Hutch--, Ya, i realized that after i posted, my mind still tends to lthe land of 16bits... i was thinking of max regsize is equivalent to ax not eax (which is ~4G)... Doh! NaN This message was edited by NaN, on 2/23/2001 12:04:50 PM
Posted on 2001-02-23 12:03:00 by NaN
This person has a UnRAR library done for VisualC: --- desc --- The URARFileLib is a small and fine peace of software that allows you to read files from RAR archives created with RAR and WinRAR. Decompression and decryption with full RAR v2.0 compatibility is done directly in your application, there is no need for a DLL or any other external file. This file library is based on the free unRAR source code by Eugene Roshal and designed for easy but powerful usage in demos and intros. This library is also useful if you want to port your demos since the URARFileLib supports multiple operating systems (Linux, SunOS and Win32). includes all source codes (ANSI C and ASM) and an example --- http://www.mountpoint.ch/unique/project/urarfilelib/
Posted on 2001-02-23 14:42:00 by newbie
Nan, Good work, just one question. Why do you GlobalAlloc Uncompressed Size + 1000? Don't you trust Jeremy's number? (Looks to me like you had initial trouble here and just added some big number to avoid a mem access crash) So vats the deal?
Posted on 2001-02-23 15:56:00 by Ernie
I havent studied the asm that makes up the actuall compression, but long story short, Jeremy Collake did it in his C++ source so i did it as well.. (my assumption on this was the decompression probabaly uses a little more memory than needed to optomise for speed and then cleaned up afterwords). All within the Black-box that is : JCALG1_Decompress_Fast NaN
Posted on 2001-02-24 16:04:00 by NaN
It's nice to see that JCALG1 is being used :). Anyway, about the +1000 in my code, that's a leftover from a long gone (at least I sure hope :)) bug that sometimes caused the decompressed size to 1-4 bytes greater than the original size (during compression, my 'optimized' phrase searching inadvertently scanned past the end of source and included the extra byte(s) in the compressed stream). Anyway, you should be able to do away with it. However, I wouldn't consider it a waste of memory to add maybe 16 bytes just in case :). I used to be confident in my code, but after a while I have learned not to absolutely trust a single thing I write until it's been subjected to years of testing :). Latez, Jeremy
Posted on 2001-03-01 08:32:00 by jcollake