-----------------------------------------
			 (X) uNdErX 2003 - underx@antisocial.com
			-----------------------------------------

		        ------------------------------------------
	        	ABOUT THE MICRO LENGTH-DISASSEMBLER ENGINE
        		------------------------------------------
	----------
	 OVERVIEW
	----------

		A  length-disassembler engine is a piece of code that allows u to know
	the length of any x86 instruction. The mlde32 engine supports the ordinary 386
	opcode set, plus the extensions: fpu, mmx, cmov, sse, sse2 etc...

	It's usage is very simple here's the prototype:

	     int __cdecl mlde32(void *codeptr);

	     where:
	     codeptr -> is a pointer to the opcode that u want to know the size.

		if  you have any  problem  using  the engine,  just take look in  some
        examples at the /examples (nothing more obvious).  That's  a very  simple  and
        powerful engine,and does not require too much system resources either,just 160
	bytes of stack space is needed. This engine is only code, and no fixed offsets
	were used so it can be permutaded/perverted at your own will.

	Obs: This engine is NOT a smaller version of Z0MBiE's LDE engine, Z0MBiE's lde
	is brilliant mine one is just awesome. :-)

        -------------------
         THE TABLE PROBLEM
        -------------------

        Everything started when i  wanted to use z0mbie's lde in some stuff that i was
        writing but i couldn't allocate a 2048 byte buffer, so i  decided to write one
        engine that doesn't needs a big table. I knew that it wouldn't be an easy task
        cuz the big  problem while writing this kind of engine, is that u need a table
        to match the opcode type from its  value, so i had created 13 types of opcodes
        and tried to  represent them with the smallest pattern i could , so i had used
        4 bits for each field of the opcode type table.
        We need 256 values to mark  the normal opcode  types and  plus 256 to mark the
        extended  ones (0Fh), so  my table got  256 bytes. That size is still big so i
        had  compressed the repeated  bit patterns, then the table was shrinked to 160
        bytes.  If i  had to  decompress that , i will surely  spend more bytes in the
        decompression  routine than  directly  looking throught the table and that was
        what i did, no decompression.

	I will be happy to receive feedbacks not only about bugs, but also concerning
        your opinions about it, or new ideas u may have, u can mail me anytime u want.

        that's all folks!
					-------//-------