The 66 prefix is used in some SIMD encodings. MOVDQA and XORPD use it though, not MOVDQU or XORPS.
It is also used with other general purpose instructions to override the operand size (on 32-bit and 64-bit mode, it switches to 16-bit operand size, and in 16-bit mode it switches to 32-bit operand size)
67, on the other hand, when used in a 64-bit process, allows you to select 32-bit address size in certain situations which may be useful.
Encoding 8B: MOV Gv, Ev; both Gv and Ev respect the operandSize override. Since you're using a memory form of Ev, it also respects addressSize override. In this case you must remove the prefixes since it will cause the encoding 66 67 8B 54 24 to become "mov dx, word [Si+0x24]" instead, causing another catastrophic problem: your 04 will no longer be part of the instruction, and will be decoded as its own instruction. At that point your program will likely catastrophically fail since you've "derailed" the instruction pointer.
They are not obsolete, but if you use them wrong, it will cause undesirable results like Spiro said.
alright, could you answer me if the code generated in raw bin (seen as this jpeg picture) is 16 bit code or what? or is this 32 bit code to run in 16 bit mode? why nasm generated it such way? it would be strange if it would generate code that purpose is tu crash anywhere.. and if not crashing would it be able to really run sse code in 16bit mode or something ? (sorry if the questions is a bit indepth, but maybe someone will know this)
ps when disasembly it was bring
c:\asm>ndisasm -b32 -o40001000h -a tezt.bin
40001000 66678B5424 mov dx,[si+0x24]
40001005 0466 add al,0x66
40001007 678B4C24 mov ecx,[si+0x24]
4000100B 080F or [edi],cl
4000100D 57 push edi
4000100E C067F30F shl byte [edi-0xd],byte 0xf
40001012 7F02 jg 0x40001016
40001014 6683C210 add dx,byte +0x10
40001018 6683E910 sub cx,byte +0x10
4000101C 7FF1 jg 0x4000100f
4000101E C3 ret
extremally wrong maybe i should try -b16
here
c:\asm>ndisasm -b16 -o40001000h -a tezt.bin
40001000 66678B542404 mov edx,[dword esp+0x4]
40001006 66678B4C2408 mov ecx,[dword esp+0x8]
4000100C 0F57C0 xorps xmm0,xmm0
4000100F 67F30F7F02 movdqu [edx],xmm0
40001014 6683C210 add edx,byte +0x10
40001018 6683E910 sub ecx,byte +0x10
4000101C 7FF1 jg 0x100f
4000101E C3 ret
seem okay but do such hex is able to run on 32 windows?
some flag i think must be setted somewhere to treat this as
some 32-16 mode (as i suspect this is 32 bit code but with some
16 bit args by default)
probably this explains most of the think - i need to find some flag
to denay this 16 bit default