Yup, compiled. You just put it in a byte array or similar and then edit memory so that a certain procedure points to the start of the array instead of the actual procedure... I haven't done it myself so I'm not too familiar with the details. I might be a bit wrong, don't really know.
jian2587: still to make it more clear: you can't make archive program of comparable speed using pure VB6 code only. You can't do that in C/C++ either, so it isn't really an issue. You can make a archive program of comparable speed if you use ASM optimized code to help you. But then we can start wondering why to make an archive program if there are great programs out there already? So... it would be more like a feature addition to a special program and there it is all the same if one will use ASM or VB6 to do it, if VB6 code is fast enough.
Wonder how long it'll take until we're fully offtopic!
Edit One last thing: having arguments is never pointless
I should've had said "lousy performer" in this regards instead, well ... perhaps ...
Well, on the one hand, we can now create deflated ZIP archives from pure VB. .
On the other hand you could've avoided a lot of confusion and anger...
BTW, I bet, with compression method 0 (STORE) I could beat Winzip.
RhinoBull said what he said, because the code given doesn't prove the original argument; that VB can write ZIP compression in PURE VB.
Huh? Look at dreamvbs link... Deflate algorithms... ZIP compression method 8... >> pure VB.
VB6 is of course out of the list, though you can still use the ASM optimized DLL.
You'll find an Add-In on PSC ("Thunder VB") which will allow you to use inline ASM.
//edit: @Rinobull: One more thing:
The question was: "Code to compress a file with ZIP compression",
not: "Code to compress a file with ZIP compression and Winzip speed and all that stuff".
I also never intended to create a perfect Winzip clone,
I just showed that creating a ZIP file in VB is possible, >with compression<.
(BTW, ZIP compression is the wrong term - ZIP files support many algorithms),
whereas you first said: "It can't be done in VB", and you didn't say anything about speed.
That was pretty strange.
Of course VB can't reach the speed of C and pure ASM. It is taken for granted that you should not use this for a commercial archiving software...
But having a class to create and extract ZIP archives for the own program is handy IMO.
You don't have to ship a big DLL for extracting some small files.
Well, I don't care about reps, I remember recently when I ask for help within someone else's thread, Penegate came and gave me a neg rep ("I'm sure it will (help), but this post won't.")
You weren't asking for help if I remember rightly, it was some comment like "I can't do it right now but someone else try it".
Originally Posted by RhinoBull
Do you guys mind to stop quoting me, it's enough already. Thanks.
I don't want to get drawn into any argument, but if you post in a thread and take part in a discussion, then others have a right to quote you IMO.
Originally Posted by Devion
Actually you can use a sorta inline asm in VB6, Seen it somewhere in a CRC32 class..
Originally Posted by Merri
...You just put it in a byte array or similar and then edit memory so that a certain procedure points to the start of the array instead of the actual procedure... I haven't done it myself so I'm not too familiar with the details. I might be a bit wrong, don't really know.
No editing memory needed. As you said, place the precompiled ASM opcodes into a byte array, and use CallWindowProc() to call the procedure. You need to make sure it pops four arguments because that is how many CallWindowProc passes.
You weren't asking for help if I remember rightly, it was some comment like "I can't do it right now but someone else try it".
I don't want to get drawn into any argument, but if you post in a thread and take part in a discussion, then others have a right to quote you IMO.
No editing memory needed. As you said, place the precompiled ASM opcodes into a byte array, and use CallWindowProc() to call the procedure. You need to make sure it pops four arguments because that is how many CallWindowProc passes.
You also could overwrite a dummy function directly with the ASM or with a JMP instruction to the ASM.
so far as I have seen, precompiled opcodes are the only way to do it. Maybe if you edited the .obj file, but that's overly complex, when this way works
Firstly, making a zip extractor + compressor is possible! Though quite impractical if not coded with very much care for optimization! Now those who say it cant let me tell u that there has been written a class that can completely decode a jpg file using pure vb! What is a jpg file its basically a 'compressed' picture file! This code uncompresses the file then loads the data! I myself am trying to make a mp3 decoder now a days in pure vb! But as others said we have performance issues! My code takes a loooooong time to only load the mp3 file in binary format! I took the smallest song i can find only 500 kbs and it took like a minute to load on my p4 2.2 ghz! But the jpg compressor is working wonders with lighting fast performance! So making a compressor/extractor is possible but quite impractical cause mp3s and .zips/.rars are files huge in size for vb! So its rather impractical but at the same place it is certainly possible!
Can someone extract the LZW dynamic with hashing code for me? Or is anyone thinks that there is a better compressor for executables, please give me that code.
Ok now forgot to mention one thing there (oooops)! Its opening the file as binary taking the value by get function and displaying it in a text box! The displaying code just blows away the speed! I remove the displaying stuff then its really fast so had to mention dat but forgot! So r u guys here planning to make one zip compressor/decompressor or just like talking about it?
Not sure; I'd be willing to give it a try to make a class-based ZIP/UNZIP.. (Winzip 9 compatible would also require some encryption/decryption routines).
Ok now forgot to mention one thing there (oooops)! Its opening the file as binary taking the value by get function and displaying it in a text box! The displaying code just blows away the speed! I remove the displaying stuff then its really fast so had to mention dat but forgot!
Wohoo, that'll be a great MP3 decoder.
Originally Posted by RapchikProgrammer
So r u guys here planning to make one zip compressor/decompressor or just like talking about it?
You may read the whole 2 pages of this thread, and check all the posted links.
Especially the ones by me and dreamvb.
I also attached my complete deflated ZIP creator project (compile it before using and only compress small files (or use compression level 0), the deflate algorithm sucks!).
The deflate code is pretty poorly coded, even with some simple math changes you can speed it up a lot. Don't know if I bother to do it... already a lot of things going on.
I just wish to add my two cents about language and their capacity (I didn't rapidely find a link in the chit chat forum) and share my knowledge about that.
If a language have theses 3 simple things:
1- register like variable (like the long format for the 32 bits)
2- the "goto" instruction
3- the "if" instruction
then you can code anything that come within the time/space complexity of current architecture of software hence the zip format.
Of course some languages are more suited for such requirement like C/C++ that handle low level byte more easily than vb (in my point of view) but in the end either can do it.
If a turing machine can do it. Vb / C/C++ / Cobol / Java to name a few can do it. Absolutely. It's only a matter of preferences and skills.
Sorry if I have bothered you I couldn't just let it go like that.
Yeah VB Can do it but very slowly! C++ is always the better choice but who wants to build binary trees and go about understanding the huffman algorithm anyway? We got winrar / winzip so wat the hell with creating a zip extractor that takes 2 minutes to compress/decompress a file!
Yeah VB Can do it but very slowly! C++ is always the better choice but who wants to build binary trees and go about understanding the huffman algorithm anyway? We got winrar / winzip so wat the hell with creating a zip extractor that takes 2 minutes to compress/decompress a file!
1) Huffman compression isn't that hard to understand. Theres some good sites out there that explain it well (if they are still around).
2) Why not? Who cares if it takes longer, at least you've learnt something from it..
Now those who say it cant let me tell u that there has been written a class that can completely decode a jpg file using pure vb! What is a jpg file its basically a 'compressed' picture file! This code uncompresses the file then loads the data!
Erm, I wouldn't agree to this either. A JPEG is yes, compressed in a way. The code that you are referring to, doesn't "decompress", it instead just loads the JPEG data. If you understand how a JPEG is compressed, it looses its quality. Kinda hard to explain, but I'm sure you get my point.
I bet u need a fusion powered shuttle to reach my place...
Posts
963
Re: ZIP Compression Using Pure Visual Basic
I find some of the posts here re-argues the same point over and over. Can we talk about something more constructive? Like what rm_03 did?
ASM,C,C++,BASIC,VB,JAVA,VBS,HTML,ASP,PHP,mySQL,VB.NET,MATLAB
Programming is fun, but only if you're not on a tight deadline
So I consider all those working engineers sad people
Agreed, some people just don't read the whole thread when they make their own statement and we end up talking the same points over and over again.
On the actual topic, I dared to take a quick minor optimization round to the deflate module and I tuned it up by about 10% - the code algorithm structure needs a complete rewrite if anyone wished for a better speed. However, there were many flawed ways to use variables and in-built functions. Here are a few common ones:
- incorrect datatypes matched against each other -> datatype coercion
- use of Variant arrays
- Fix(Number / Value) instead of Number \ Value - the latter is many times faster
- pointing to same array item multiple times within the same line instead of storing it to a variable
- using * when + could be used for faster math (ie. Number * 2 -> Number + Number)
- initializing static values to variables instead of constants with heavy math (such as Variable = 2 ^ 30)
I bet u need a fusion powered shuttle to reach my place...
Posts
963
Re: ZIP Compression Using Pure Visual Basic
Merri...I wonder if you wrote any programming books?
ASM,C,C++,BASIC,VB,JAVA,VBS,HTML,ASP,PHP,mySQL,VB.NET,MATLAB
Programming is fun, but only if you're not on a tight deadline
So I consider all those working engineers sad people
Zip uses an algorithm called Deflate to do compression. It does the compression in two steps. The first part (LZ77) should be fairly simple. As it goes along it checks for previous copies of the current data, and if there aren't copies, it produces a literal representation of the data, and if it finds past copies it puts an offset/length pair to the previous copy instead of a literal representation of the data. The second step is huffman compression, which finds which are the most common symbols, and then the more common symbols get shorter bit lengths (so now some symbols will be less than one byte long, which means the data is now being handled at the bit level, not the byte level, and this can get VERY VERY VERY tricky in raw VB code, and so far I've never been able to write a successful huffman algorithm in VB6). So while it should theoretically be possible, the writing of the compression algorithm may very well take up the majority of the time you are spending on writing your program. Not to mention a raw VB6 implementation of the compression algorithm will likely run VERY VERY VERY slowly (due to the complexity of the algorithm, and the fact that VB6 runs MUCH slower than C++, Pascal, Delphi, and 99% of the other programming languages out there).
I'd like to add my 2 cents here, even though this is not Zip compression (deflate....lz77/huffman).
It encodes into huffman code, but my tree is not optimized so it will not compress at it's best but it compresses a lot already.
Also it will not write to file but if you take a quick look at text3.text (once click on Show Binary) this would be what would be in a file (to be read), the only thing missing is the header with how many extra 0 (bits) there is at the end, file length and the characters in order (from the most frequent to less frequent).
Although winzip uses LZ77 (which should be easier than huffman) and huffman, I'm sure their tree is created different, but the point here is that it can be done, I have shown you huffman code (without the proper tree format) but it is still huffman (compression) code.
It is not hard to make, but a bit harder to make it fast like winzip.
Here is the project. I will update it whenever I can.
Reply With Quote
.
Originally Posted by inventrex
