Prefix codes 66 and 67 are available even in 32 and 64 bit modes. They are called operand size prefix and address size prefix. The CPU determines the default operand and address sizes from the D bit in the segment descriptors. With these prefixes this can be overriden for single instructions.
AFAIK this is extended for segments with 32 Bit and 64 bit as well. For some SIMD instructions this prefix is mandantory. If you want to know more about that read the programming manuals.

Prefix codes 66 and 67 are available even in 32 and 64 bit modes. They are called operand size prefix and address size prefix. The CPU determines the default operand and address sizes from the D bit in the segment descriptors. With these prefixes this can be overriden for single instructions.
AFAIK this is extended for segments with 32 Bit and 64 bit as well. For some SIMD instructions this prefix is mandantory. If you want to know more about that read the programming manuals.

alright tnx for info this was ok,

as to D bit in segment descriptor -

does maybe someone know if i could mix such say 16 32 and 64 segments in one app ? what is setting this - windows loader based on some program image, or what.. ?

In modern os the segment registers are only set once by the os. They use a flat memory model. Access to the segment descriptors is only possible by the os. Changing the segment registers to some value other than they are set after startup, shall lead to crash/exception.

In modern os the segment registers are only set once by the os. They use a flat memory model. Access to the segment descriptors is only possible by the os. Changing the segment registers to some value other than they are set after startup, shall lead to crash/exception.

alright

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

Exactly - the behavior depends on BOTH the CPU's mode for the process (16-bit, 32-bit, or 64-bit are the ones that x86-64 processors support currently) AND the prefix of the instruction. Your encodings were built to be executed in 16-bit mode (this is why the 32-bit operands got assembled with 66 and 67 prefixes). Microsoft PE files (EXEs and DLLs) have field(s) in the headers which specifies which processor and mode the code should be executed in.

Current Windows programs should always target either 32-bit or 64-bit modes, since 16-bit executables are no longer supported on 64-bit editions of Windows.