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
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
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
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
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, email@example.com
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:
Extra Includes (Thanx to Jeremy Collake for his hard work)
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
And the SaveFile Addin's
include \MASM32\INCLUDE\jcalg1_proto.inc includelib \MASM32\LIB\jcalg1_static.lib
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
invoke FillBuffer,ADDR szFileName,length szFileName,0 invoke SaveFileName,hWin,ADDR szTitleS,ADDR szFilterS cmp szFileName,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 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
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, firstname.lastname@example.org
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.
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
I found it at the official rar site - http://www.rarsoft.com. I think it should still be there?
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
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
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/
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?
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
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