This message was edited by Janib4all at 2005-2-12 4:31:15

---

Hi! Guys. Im Janib4all.
And Im In Deep Trouble.
I've Made A Compressor Fully In X86-Asm [Real Mode].
Works Somewhere Better Than .Zip .Lzh .Rar .Arj And SomeTimes It Need
Compressing Same File Again n Again To Get Better Results. But The
Problem Is Not This.
It Is Tooooo Slow.

I Use 450-PIII.
Some Observations:

-----------------------------------------------------------------
 Input_File: Conctl32.Ocx
 File_Size : 609,584 kbs
  
 Compressor-Name:             Compression-Ratio:          Time:
------------------          ----------------------       --------
 a) Jip (My Compressor)      187,455 kbs = 30.75%         46 Sec
 b) Zip                      236,559 kbs = 38.80%         <1 Sec
 c) Arj                      245,918 kbs = 40.34%         <1 Sec
 d) Lzh                      257,535 kbs = 42.41%         <1 Sec

-----------------------------------------------------------------

So U See My Compressor [Based On Lzw Compression Algoritm + Some
My Algorithm + Fully Written By Me] Is Better Than Other Compressors
In Size, But It Is Worst Choice In Speed.
And I Dont Know How To Increase Speed. Of My Prog.
One Big Problem Is That I've Used Only BYTE Not WORD. [U Know ]
It Is Fully Based On X86Asm Real Mode.
One Other Thing, If U Compress, This Compressed .Jip File Again-n-Again,
It Reduces And Reduces Size.

After Compressing Comctl32.Jip 2nd Time
--------------------------------------------------
Comctl32.Jip = 150,850 kbs


After Compressing Comctl32.Jip 3rd Time
--------------------------------------------------
Comctl32.Jip = 129,604 kbs


Final Compressing Comctl32.Jip After Many Times [More-than 50 Times]
--------------------------------------------------------------------
Comctl32.Jip = <> 20 kbs - Wow!


Plz, Help Me.
I Can Also Send You Compiled Version Of My Compressor.
[Unpacking Not Done, Due To This Problem]
My Email Is Janib4all@hotmail.com

: This message was edited by Janib4all at 2005-2-12 4:31:15

---

:

: Hi! Guys. Im Janib4all.
: And Im In Deep Trouble.
: I've Made A Compressor Fully In X86-Asm [Real Mode].
: Works Somewhere Better Than .Zip .Lzh .Rar .Arj And SomeTimes It Need
: Compressing Same File Again n Again To Get Better Results. But The
: Problem Is Not This.
: It Is Tooooo Slow.
: 
: I Use 450-PIII.
: Some Observations:
: 
: -----------------------------------------------------------------
:  Input_File: Conctl32.Ocx
:  File_Size : 609,584 kbs
:   
:  Compressor-Name:             Compression-Ratio:          Time:
: ------------------          ----------------------       --------
:  a) Jip (My Compressor)      187,455 kbs = 30.75%         46 Sec
:  b) Zip                      236,559 kbs = 38.80%         <1 Sec
:  c) Arj                      245,918 kbs = 40.34%         <1 Sec
:  d) Lzh                      257,535 kbs = 42.41%         <1 Sec
: 
: -----------------------------------------------------------------
: 
: So U See My Compressor [Based On Lzw Compression Algoritm + Some
: My Algorithm + Fully Written By Me] Is Better Than Other Compressors
: In Size, But It Is Worst Choice In Speed.
: And I Dont Know How To Increase Speed. Of My Prog.
: One Big Problem Is That I've Used Only BYTE Not WORD. [U Know ]
: It Is Fully Based On X86Asm Real Mode.
: One Other Thing, If U Compress, This Compressed .Jip File Again-n-Again,
: It Reduces And Reduces Size.
: 
: After Compressing Comctl32.Jip 2nd Time
: --------------------------------------------------
: Comctl32.Jip = 150,850 kbs
: 
: 
: After Compressing Comctl32.Jip 3rd Time
: --------------------------------------------------
: Comctl32.Jip = 129,604 kbs
: 
: 
: Final Compressing Comctl32.Jip After Many Times [More-than 50 Times]
: --------------------------------------------------------------------
: Comctl32.Jip = <> 20 kbs - Wow!
: 
: 
: Plz, Help Me.
: I Can Also Send You Compiled Version Of My Compressor.
: [Unpacking Not Done, Due To This Problem]
: My Email Is Janib4all@hotmail.com
: 

:

wow,great thing.nobody has ever found a compression algorithmus which will result in unlimited compression.after a few cycles a best compression ratio for a given file and a given method has been reached.most packers never use a maximum theoretically possible pack-ration for speed and memory-usage(LZH for example may result in VERY huge lookup-tables for larger files) reasons.

i strongley suggest you first write an unpacker and test it.pack a file 5..10 times and unpack it afterwards.is all the data still ok?nothing corrupted?

you can use MMX for example to do some things parallel,optimize loops for code/data prefetching and so on.BEFORE starting optimizing you should verify that your packer / unpacker works correctly...

This message was edited by Janib4all at 2005-2-16 0:43:2

---

: :

: : Hi! Guys. Im Janib4all.
: : And Im In Deep Trouble.
: : I've Made A Compressor Fully In X86-Asm [Real Mode].
: : Works Somewhere Better Than .Zip .Lzh .Rar .Arj And SomeTimes It Need
: : Compressing Same File Again n Again To Get Better Results. But The
: : Problem Is Not This.
: : It Is Tooooo Slow.
: : 
: : I Use 450-PIII.
: : Some Observations:
: : 
: : -----------------------------------------------------------------
: :  Input_File: Conctl32.Ocx
: :  File_Size : 609,584 kbs
: :   
: :  Compressor-Name:             Compression-Ratio:          Time:
: : ------------------          ----------------------       --------
: :  a) Jip (My Compressor)      187,455 kbs = 30.75%         46 Sec
: :  b) Zip                      236,559 kbs = 38.80%         <1 Sec
: :  c) Arj                      245,918 kbs = 40.34%         <1 Sec
: :  d) Lzh                      257,535 kbs = 42.41%         <1 Sec
: : 
: : -----------------------------------------------------------------
: : 
: : So U See My Compressor [Based On Lzw Compression Algoritm + Some
: : My Algorithm + Fully Written By Me] Is Better Than Other Compressors
: : In Size, But It Is Worst Choice In Speed.
: : And I Dont Know How To Increase Speed. Of My Prog.
: : One Big Problem Is That I've Used Only BYTE Not WORD. [U Know ]
: : It Is Fully Based On X86Asm Real Mode.
: : One Other Thing, If U Compress, This Compressed .Jip File Again-n-Again,
: : It Reduces And Reduces Size.
: : 
: : After Compressing Comctl32.Jip 2nd Time
: : --------------------------------------------------
: : Comctl32.Jip = 150,850 kbs
: : 
: : 
: : After Compressing Comctl32.Jip 3rd Time
: : --------------------------------------------------
: : Comctl32.Jip = 129,604 kbs
: : 
: : 
: : Final Compressing Comctl32.Jip After Many Times [More-than 50 Times]
: : --------------------------------------------------------------------
: : Comctl32.Jip = <> 20 kbs - Wow!
: : 
: : 
: : Plz, Help Me.
: : I Can Also Send You Compiled Version Of My Compressor.
: : [Unpacking Not Done, Due To This Problem]
: : My Email Is Janib4all@hotmail.com
: : 

: :
:
: wow,great thing.nobody has ever found a compression algorithmus which will result in unlimited compression.after a few cycles a best compression ratio for a given file and a given method has been reached.most packers never use a maximum theoretically possible pack-ration for speed and memory-usage(LZH for example may result in VERY huge lookup-tables for larger files) reasons.
:
: i strongley suggest you first write an unpacker and test it.pack a file 5..10 times and unpack it afterwards.is all the data still ok?nothing corrupted?
:
: you can use MMX for example to do some things parallel,optimize loops for code/data prefetching and so on.BEFORE starting optimizing you should verify that your packer / unpacker works correctly...
:

Thanks for replay .....
im not a regular assembly student, thats why i dont know many things like MMX !!! What is It ???. And Can it optimize my code...
And im little bit lazy ..... and not in mood of making unpacker...now..
many take some time.
i've made some optimization stuff. and now it take 10 seconds for 200kbs. instead of 11 seconds for 100kbs. good...
but having some problem in hooking int 08h and when work is dont set it to its real address....
ask me for compiled version and test it on ur pc and give my some results becaus i hav'nt tested it on any other pc.
and im not publish the source code, not becauz of that u may copy it and publish it with ur name. not jellousy. i want to make this code without any help.
i use 450 mzh P-III. Windows ME Arabic.
And Please send me some code about 8253 Pit.
i want to increase speed about 5000 times .....
janib4all@hotmail.com
{bad english

: : wow,great thing.nobody has ever found a compression algorithmus which will result in unlimited compression.after a few cycles a best compression ratio for a given file and a given method has been reached.most packers never use a maximum theoretically possible pack-ration for speed and memory-usage(LZH for example may result in VERY huge lookup-tables for larger files) reasons.
: :
: : i strongley suggest you first write an unpacker and test it.pack a file 5..10 times and unpack it afterwards.is all the data still ok?nothing corrupted?
: :
: : you can use MMX for example to do some things parallel,optimize loops for code/data prefetching and so on.BEFORE starting optimizing you should verify that your packer / unpacker works correctly...
: :
:
: Thanks for replay .....
: im not a regular assembly student, thats why i dont know many things like MMX !!! What is It ???. And Can it optimize my code...
: And im little bit lazy ..... and not in mood of making unpacker...now..
: many take some time.
: i've made some optimization stuff. and now it take 10 seconds for 200kbs. instead of 11 seconds for 100kbs. good...
: but having some problem in hooking int 08h and when work is dont set it to its real address....
: ask me for compiled version and test it on ur pc and give my some results becaus i hav'nt tested it on any other pc.
: and im not publish the source code, not becauz of that u may copy it and publish it with ur name. not jellousy. i want to make this code without any help.
: i use 450 mzh P-III. Windows ME Arabic.
: And Please send me some code about 8253 Pit.
: i want to increase speed about 5000 times .....
: janib4all@hotmail.com
: {bad english
:
:
:

well,i think you havent understand me.you packer may have some errors.ive written something similiar a few years ago and missed to flush the last bit in each output buffer.after 10000 cycles more than 1kb has been 'saved'.and this each time you repacked the packed file with my program.wow,impressiv!!one day later i tried to unpack the data and noticed the problem.

i strongley suggest you try to unpack your file before spending lots of time in optimizing your packer.

: well,i think you havent understand me.you packer may have some errors.ive written something similiar a few years ago and missed to flush the last bit in each output buffer.after 10000 cycles more than 1kb has been 'saved'.and this each time you repacked the packed file with my program.wow,impressiv!!one day later i tried to unpack the data and noticed the problem.
:
: i strongley suggest you try to unpack your file before spending lots of time in optimizing your packer.
:

ok. but im not going to start unpacking routine until this speed problem is solved.
and u say that u mis some bytes . well i've tried about 20 times in one small file, the result was always constant ...
give me ur email to send u my files ...
try it, specially on 100kb or lessthan 500kb, beacauz it is too slow..
and wait.
whenever we compress some files with Pkzip, and try to compress that Ziped file again and again, nothing happens. even it we try to compress it with some other compressor. a little effect is seen. but my compressor can pack anyother compressed file too.
becauz other compressed put some signature in their compressed file . and when those files are compressed again, the compressor refuse to compress that file or take little effort. but i havn't implimanted this thing yet in my compressor. thats why it can compress again n again, same file.
plz. try it and show me results....

I've lost the code, otherwise, would have published here or sent to you guys to see what went wrong in it?

: Hi! Guys. Im Janib4all.

: Input_File: Conctl32.Ocx
: File_Size : 609,584 kbs

: Final Compressing Comctl32.Jip After Many Times [More-than 50 Times]
: Comctl32.Jip = <> 20 kbs - Wow!

Thank you very much Janib4all!! I can't remember the last time I laughed this hard. That is a real treat!

Nathan.

: : Hi! Guys. Im Janib4all.
:
: : Input_File: Conctl32.Ocx
: : File_Size : 609,584 kbs
:
: : Final Compressing Comctl32.Jip After Many Times [More-than 50 Times]
: : Comctl32.Jip = <> 20 kbs - Wow!
:
: Thank you very much Janib4all!! I can't remember the last time I laughed this hard. That is a real treat!
:
: Nathan.
:
:
If you get this thing to work? You are on a vacation for the rest of your life

But i think your data will never come back in 1 piece. What Crow allready said: make that unpacker.

: : : Hi! Guys. Im Janib4all.
: :
: : : Input_File: Conctl32.Ocx
: : : File_Size : 609,584 kbs
: :
: : : Final Compressing Comctl32.Jip After Many Times [More-than 50 Times]
: : : Comctl32.Jip = <> 20 kbs - Wow!
: :
: : Thank you very much Janib4all!! I can't remember the last time I laughed this hard. That is a real treat!
: :
: : Nathan.
: :
: :
: If you get this thing to work? You are on a vacation for the rest of your life
:
: But i think your data will never come back in 1 piece. What Crow allready said: make that unpacker.
:
:

There was an column once in DDJ (Algorithms column, I think, by Michael Swaine; I need to verify) about an alien landing on earth and crunching/encrypting all writings (or is it all data, I forgot) into a single yardstick.

Sounds farfetched? Maybe, but Swaine has convincingly explained how that could happen. Perhaps it's the same as Janib4all's case.

And then again, Swaine did emphasize the need for a good decrypting algorithm, for the data contained in the yardstick to be of use.


: And im little bit lazy ..... and not in mood of making
: unpacker...now..

A little friendly advice, as pointed out by CroW and diehard... Write the unpacker before making any more optimizations, otherwise, you might just waste a lot of resources by trying to optimize something, only to find out later that there really was a bug in the packer.

hi, guys, im sorry, it was a mistake ... to tell you all headless monkies about my prog ...
sorry ... dont give any comments of this topic . plz.
i've deleted my source code .. and a'int going to make any other prog ..

: hi, guys, im sorry, it was a mistake ... to tell you all headless monkies about my prog ...
: sorry ... dont give any comments of this topic . plz.
: i've deleted my source code .. and a'int going to make any other prog ..
:

assembly is complex,it takes a long time to get a good coder.it requires to go step by step,learn one thing and do the next step when the previous one is fully understood.exspecially for beginners it makes no sense to work do five things at the same time.try to finish one thing before starting something new or none of your projects ever get finished.Im personally coding x86 for 7 years now,many of the guys here are doing it even longer,maybe one or two of their advises make sense?

this board is for learning assembly and sharing problems with other coders.giving up after one single mistake isnt surly the way to learn anything.Im sad to hear youve deleted all our sources,it could have been interesting to see how your project (and the 5 others) develope.its always a good feeling to get something work.thats another thing you may share here to keep a nice friendly atmosphare.

good luck&have fun with codin,thats what its all about

This message was edited by shaolin007 at 2005-2-24 14:33:32

---

assembly is complex,it takes a long time to get a good coder.it requires to go step by step,learn one thing and do the next step when the previous one is fully understood



Boy isn't that an understatement! That's pretty much been my life so far learning this language! Well I have about 2 years under my belt of being self taught. I think I might be on track. I think...

: This message was edited by shaolin007 at 2005-2-24 14:33:32

---

:
: assembly is complex,it takes a long time to get a good coder.it requires to go step by step,learn one thing and do the next step when the previous one is fully understood
:
:
:
: Boy isn't that an understatement! That's pretty much been my life so far learning this language! Well I have about 2 years under my belt of being self taught. I think I might be on track. I think...
:
:
Indeed, assembly is in the beginning hard to learn, but when you get the picture its nice to do. I see it as some sort of brain gym ;) so i dont get stupid of all that beer in the weekend :P

But every time i start a project, the main idea looks so damn simpel. Well again and again it isnt. I love that of assembly. I didnt have programmed in assembly for a 1/2 year now, and really need to startup again. But that is going ok now :) I programming now my own assembler. Im happy that the hunger has come back to program, i walked a 1/2 year with the idea to program that assembler.

If the plain idea/plan/text on paper is ok, it will be smaller and faster then all the other assembler. Because some self made assembler routine ;) Well we see that later.

But it is good to see some people that still are on this forum...

Cheers.

Hi. Guys, Im Sorry.
and i have'nt deleted my source code. the thing is that i dont want anyones skill in my compressor, i'll probably share it after it is done. it is based on LZW algorithm.
i did a mistake. when i saw that algorithm, it looked simple, so i convert it to x86, but put one little trick in it, and thought it might work, i was not sure, and made me compressor, but after seeing the results it is obvious that i was rong. i can change it anytime i want, but from now im busy doing some eduction stuff ( B-Com ).
and dont tell me that x86-asm is hard, i know, it is hard, but u dont tell me in this case.
whenever, i find myself unable to make a complete compressor, i'll surely ask u guys.

why, i put me own trick in LZW ALGORITHM?
simple. i wanted to make the smallest compressor ever.
but now after changing or deleting my trick, it's result will be equal to LHA OR ZIP!
but it probably need time ...
ok. when Packing Routine is done, i'll publish here. and let me see you cool guys can make THE UNPACKER.

: This message was edited by Janib4all at 2005-2-12 4:31:15

---

:

: Hi! Guys. Im Janib4all.
: And Im In Deep Trouble.
: I've Made A Compressor Fully In X86-Asm [Real Mode].
: Works Somewhere Better Than .Zip .Lzh .Rar .Arj And SomeTimes It Need
: Compressing Same File Again n Again To Get Better Results. But The
: Problem Is Not This.
: It Is Tooooo Slow.
: 
: I Use 450-PIII.
: Some Observations:
: 
: -----------------------------------------------------------------
:  Input_File: Conctl32.Ocx
:  File_Size : 609,584 kbs
:   
:  Compressor-Name:             Compression-Ratio:          Time:
: ------------------          ----------------------       --------
:  a) Jip (My Compressor)      187,455 kbs = 30.75%         46 Sec
:  b) Zip                      236,559 kbs = 38.80%         <1 Sec
:  c) Arj                      245,918 kbs = 40.34%         <1 Sec
:  d) Lzh                      257,535 kbs = 42.41%         <1 Sec
: 
: -----------------------------------------------------------------
: 
: So U See My Compressor [Based On Lzw Compression Algoritm + Some
: My Algorithm + Fully Written By Me] Is Better Than Other Compressors
: In Size, But It Is Worst Choice In Speed.
: And I Dont Know How To Increase Speed. Of My Prog.
: One Big Problem Is That I've Used Only BYTE Not WORD. [U Know ]
: It Is Fully Based On X86Asm Real Mode.
: One Other Thing, If U Compress, This Compressed .Jip File Again-n-Again,
: It Reduces And Reduces Size.
: 
: After Compressing Comctl32.Jip 2nd Time
: --------------------------------------------------
: Comctl32.Jip = 150,850 kbs
: 
: 
: After Compressing Comctl32.Jip 3rd Time
: --------------------------------------------------
: Comctl32.Jip = 129,604 kbs
: 
: 
: Final Compressing Comctl32.Jip After Many Times [More-than 50 Times]
: --------------------------------------------------------------------
: Comctl32.Jip = <> 20 kbs - Wow!
: 
: 
: Plz, Help Me.
: I Can Also Send You Compiled Version Of My Compressor.
: [Unpacking Not Done, Due To This Problem]
: My Email Is Janib4all@hotmail.com
: 

:
I believe it is impossible to reduce arbitrarily the size of a file by compression. It is related with data redundance. Compressors reduce size by removing redundant information. But you cannot remove the remaining info, otherwise you'd lose data.

: I believe it is impossible to reduce arbitrarily the size of a file by compression. It is related with data redundance. Compressors reduce size by removing redundant information. But you cannot remove the remaining info, otherwise you'd lose data.
:

Sorry, but this is completely wrong. I wrote a compression algorythm that can compress files of any size down to 0 bytes!

:
: : I believe it is impossible to reduce arbitrarily the size of a file by compression. It is related with data redundance. Compressors reduce size by removing redundant information. But you cannot remove the remaining info, otherwise you'd lose data.
: :
:
: Sorry, but this is completely wrong. I wrote a compression algorythm that can compress files of any size down to 0 bytes!
:

Gosh, really??? 8-O
That's wonderful! You realize, since any file can be compressed to the same archive of 0 bytes, by decompressing an archive you can generate whatever program you may want, all absolutely free!!!! That's a great innovation!

: Gosh, really??? 8-O
: That's wonderful! You realize, since any file can be compressed to the same archive of 0 bytes, by decompressing an archive you can generate whatever program you may want, all absolutely free!!!! That's a great innovation!
:

Sorry, but it is obvious to me that you don't understand very much about this topic. Maybe you should read some introductory books on computers.

Anyway your assumption is wrong. The only problem I have with my algorythm is that somehow decompression doesn't work yet. Very strange.

: : Gosh, really??? 8-O
: : That's wonderful! You realize, since any file can be compressed to the same archive of 0 bytes, by decompressing an archive you can generate whatever program you may want, all absolutely free!!!! That's a great innovation!
: :
:
: Sorry, but it is obvious to me that you don't understand very much about this topic. Maybe you should read some introductory books on computers.
:
: Anyway your assumption is wrong. The only problem I have with my algorythm is that somehow decompression doesn't work yet. Very strange.
:

ok,i suggest you make yourself familiar with the work of claude shannon on which most data-encoding today is based.its about the word 'information' and what its all about.you can change the way a information is encoded,but as more information a packet carries as more bits are needed to encode the package.

in generell all compression algorithms dont loose any informations,they just optimize the symbol size ot reduze filesize.however,in some multimedia files some informations arnt as important than others and you can save some bytes by throw some data away.mp3 and jpg are 2 examples for data-llosing compression.

google for information,entropie,optimal coding,shannon,fano
and read it carefully.afterwards go to your local patent office and you get a rich man by founding out that 150 years of information theory are outdated ;)

This message was edited by octavio2 at 2005-3-8 15:25:31

---

: Gosh, really??? 8-O
: That's wonderful! You realize, since any file can be compressed to the same archive of 0 bytes, by decompressing an archive you can generate whatever program you may want, all absolutely free!!!! That's a great innovation!
:

Is not a innovation at all latest DOS versions include a compressor and a decompressor that compress any file to 0 bytes in a insignificant amount of time, the only problem is that with those leves
of compresion Quantum Mechanics become very important and because of the Uncertainty Principle from Werner Heisenberg some times the file can not be decompresed.
compression programs are 'delete' and 'undelete' :)

: This message was edited by octavio2 at 2005-3-8 15:25:31

---

: : Gosh, really??? 8-O
: : That's wonderful! You realize, since any file can be compressed to the same archive of 0 bytes, by decompressing an archive you can generate whatever program you may want, all absolutely free!!!! That's a great innovation!
: :
:
: Is not a innovation at all latest DOS versions include a compressor and a decompressor that compress any file to 0 bytes in a insignificant amount of time, the only problem is that with those leves
: of compresion Quantum Mechanics become very important and because of the Uncertainty Principle from Werner Heisenberg some times the file can not be decompresed.
: compression programs are 'delete' and 'undelete' :)
:
:
:
:
:
LOL! Couldn't imagine x86 asm was so funny :)

hi,guys, i wanna to make compressor from HUFFMAN ALGORITHM.
i know how it assign frequencies to bytes, but m unable to translate it in Code X86Asm.
can any one help.