5 ms·

According to Wikipedia Windows 64 bit runs 32 bit apps by switching back to 32 bit mode. > which switches the processor hardware from its 64-bit mode to compat

by 21 9y ago

According to Wikipedia Windows 64 bit runs 32 bit apps by switching back to 32 bit mode. > which switches the processor hardware from its 64-bit mode to compatibility mode when it becomes necessary to execute a 32-bit thread, and then handles the switch back to 64-bit mode. https://en.wikipedia.org/wiki/WoW64 https://en.wikipedia.org/wiki/WoW64

kobeya 9y ago
I don’t honk this is correct. Iirc moving to 64 but more is a one way street. Rather, there is a virtual 32 but compatibility mode provided in the 64 bot environment, and that is probably what is being referred to here.
0x0 9y ago
Isn't it more about just loading cs/ds/es segments with 32bit selectors? For example there's the "heaven's gate" trick on windows to sneak through the wow64 layer directly into the other modes - http://rce.co/knockin-on-heavens-gate-dynamic-processor-mode-switching/ http://rce.co/knockin-on-heavens-gate-dynamic-processor-mode...
dfox 9y ago
"Compatibility mode" is sub-mode of long mode which has limited support for 16/32b i386-style memory segmentation (notably there is no support for vm86 code segments and gate descriptors have different format and can only reference 64bit "segments"). It is clear that AMD's intention for this was to implement just enough of segmentation in long mode to allow compatibility with segment-aware user-space code (eg. mixed 16/32b Windows userspace) but there does not seem to be any OS that actually uses 16bit descriptors in long mode (probably due to the mechanism being significantly different than i386's 16/32 compatibility). For compatibility with "normal" flat address space user space code the whole mechanism could be significantly simpler and have same "segmantation" behavior as 64b mode, have 32b EIP pushed on stack by CALL/RET and trap on anything that tries to load new selector anywhere (ie JMP/CALL/RET FAR, MOV whatever, ?S), even REX prefix could be supported in such an "limited compatibility mode" and we would not have to invent things like x32_abi (which is to some extent the same idea, although with different motivations, ie. run new ABI-incompatible 32b code in 64b mode to gain access to new registers and instructions while having 32b pointers and thus reduced memory footprint).

by 21 9y ago

kobeya 9y ago

I don’t honk this is correct. Iirc moving to 64 but more is a one way street. Rather, there is a virtual 32 but compatibility mode provided in the 64 bot environment, and that is probably what is being referred to here.

0x0 9y ago

Isn't it more about just loading cs/ds/es segments with 32bit selectors? For example there's the "heaven's gate" trick on windows to sneak through the wow64 layer directly into the other modes - http://rce.co/knockin-on-heavens-gate-dynamic-processor-mode-switching/ http://rce.co/knockin-on-heavens-gate-dynamic-processor-mode...

dfox 9y ago

"Compatibility mode" is sub-mode of long mode which has limited support for 16/32b i386-style memory segmentation (notably there is no support for vm86 code segments and gate descriptors have different format and can only reference 64bit "segments"). It is clear that AMD's intention for this was to implement just enough of segmentation in long mode to allow compatibility with segment-aware user-space code (eg. mixed 16/32b Windows userspace) but there does not seem to be any OS that actually uses 16bit descriptors in long mode (probably due to the mechanism being significantly different than i386's 16/32 compatibility). For compatibility with "normal" flat address space user space code the whole mechanism could be significantly simpler and have same "segmantation" behavior as 64b mode, have 32b EIP pushed on stack by CALL/RET and trap on anything that tries to load new selector anywhere (ie JMP/CALL/RET FAR, MOV whatever, ?S), even REX prefix could be supported in such an "limited compatibility mode" and we would not have to invent things like x32_abi (which is to some extent the same idea, although with different motivations, ie. run new ABI-incompatible 32b code in 64b mode to gain access to new registers and instructions while having 32b pointers and thus reduced memory footprint).