5 ms·
With the “new”/32-bit-code-in-64-bit-process Wow64, the Unix process and all Unix code/shared libraries are 64-bit. But (most of) the Windows code is 32-bit, an
by mrpippy 3y ago
With the “new”/32-bit-code-in-64-bit-process Wow64, the Unix process and all Unix code/shared libraries are 64-bit. But (most of) the Windows code is 32-bit, and calls through thunks to Unix code (either Nt* syscalls or into Unix libs).
I don’t think there’s much of a performance effect, if anything it should be faster since all the Unix code running is 64-bit (and x86_64 has more registers, newer ISA extensions). You also don’t have to worry about Unix libraries eating up precious 32-bit address space.
The only current downside is OpenGL/Vulkan calls that return (64-bit) pointers to memory, those buffers need to be copied to 32-bit before being returned to the application. A Vulkan extension is in the works for that.
- vlovich123 3y agoThat doesn’t make sense. You can’t intermingle 32 bit and 64bit code in the same process at all afaik. This is a CPU decision. An obvious problem is the fact that 32bit applications will use 32bit addressing modes which are illegal when the processor is running in 64-bit mode. Wow64 is just a support library to make 32bit apps run in a 64-bit OS, but that library itself is 32-bit. If you have any supporting evidence to the contrary I’d love to read it because it’ll blow up my conception of how multi arch works on 64-bit.
- jchw 3y agoThe term to search for is "heaven's gate". TL;DR: Intel processors can, in usermode, switch between 32-bit and 64-bit mode. Note that the concept of a process is irrelevant: processes don't exist to Intel processors. There was a concept called a "task" early on in I believe the 286 line, but nowadays all OSes just set up a single task segment on the CPU and do all of the context switching via other means, because it simply wound up being faster anyway. The processor just has tons of registers that you can flip around, and being able to switch between protected mode and long mode is a property of the code segment currently being executed (IIRC) which is something you can jump between in usermode using a far call. (And this is, as far as I know, just about the only way in which x86 segments remain relevant today.)
- vlovich123 3y agoWhen I said processes, my impression was that the kernel was responsible for switching the CPU into / out of 32-bit mode through a privileged operation (ie that’s the process boundary). Turns out that’s not the case and it’s in the unprivileged CS register which can be mutated calling jmp/call with a target segment set to 0x33. Thanks for correcting me! [1] https://stackoverflow.com/questions/24113729/switch-from-32bit-mode-to-64-bit-long-mode-on-64bit-linux#32384358 https://stackoverflow.com/questions/24113729/switch-from-32b...
- krackers 3y agoI assume this one for heaven's gate: https://www.alex-ionescu.com/closing-heavens-gate/ https://www.alex-ionescu.com/closing-heavens-gate/ But that's very windows specific, I think the general term is jumping between long mode and protected mode?
- jchw 3y agoI'm not sure exactly where the term comes from, but I've seen people use it to refer to doing the same thing on Linux, too. (IIRC, the code segments for protected mode and long mode also happen to be the same on Windows and Linux. Not sure why exactly.)
- nextaccountic 3y agoIntel processors can, as opposed to AMD processors? or both can?
- jchw 3y agoSorry, both.
- mrpippy 3y agoYou can mix 32- and 64-bit code in a 64-bit process on both Linux and macOS (since 10.15), and this is what Wine uses. It works by setting a LDT with a 32-bit code segment and then doing a far/long cross-segment jump to the 32-bit segment. 32-bit code runs, and it jumps back to the 64-bit segment for Nt* “syscalls”, Unix lib calls, and signals.
- mjan22640 3y agoThe CPU runs in either 32bit or 64bit mode. That determines how it interprets the code. A CPU in 64bit mode would interpret 32bit code as 64bit garbage and vice versa.