Hi there,
I was just wondering whether an address-size override prefix was even valid under 32bits, because its displacement could only address the first 0FFFFh Bytes which are reserved.
I also tried the following:

which actually should move 'MZ' into ax, shouldn't it? It doesn't seem to work, though.

So if 16bits addressing is apparently invalid under x86, then what is the 67h-prefix for?
Under x64, addressing with such a prefix apparently doesn't change the size of the displacement, but only the registers (rax -> eax) which remains valid.

The 67h prefix is pretty useless in Windows, because Windows never maps memory in 00000000-0000FFFF unless you force it to. (It's still not completely invalid though: "lea eax,[bx+di+0FFFFh]" uses a 67h prefix but would not crash. With BX=0FFFFh and DI=2, it will load an effective address of 0.)

The 67h prefix was much more useful in the early days of the 386 when you would often have a mixture of 16-bit and 32-bit code in a program.

Thanks for your reply
Kind of expected 0FFFFh+0FFFFh+2 to result in 20000h, which is actually pretty dumb because then again it wouldn't be 16bits-addressing anymore..

Tried to map an exe into 0000-FFFF which doesn't seem to work. Also I've read somewhere that it'd be a protected memory area where windows maps its information.

Windows is not the only OS that runs in 32-bit protected mode.

As for 32-bit Windows, accesses to FS segment can use 16-bit memory access since the accessible area starts at offset zero.

You can also create your own segment in 32-bit Windows (even in user mode) with legal offset of zero but this is rather tricky and undocumented.

In 64-bit Windows, if you're sure your memory is accessible using 32-bit offset, you can use the prefix too.

Think about LEA.