I fail to see how Linux support for 32-bit syscalls here is relevant. The reason they need 32-bit libraries is that the original 32-bit windows app needs to run with the CPU in 32-bit mode. That means all the original DLLs and support libraries need to run in 32-bit as well. None of that has to do with Linux syscalls. So all the 32-bit components would still need to thunk to an out of process wine64 instance and that seems like an architecture that will perform poorly vs just having a 32bit build continue.
From my research the situation is a bit murkier in that even 64-bit wine seems to require 32-bit components for some reason but that may be a basic packaging issue and the real blocker.
Do you have any supporting links I can read for your claims? I haven’t been able to find anything.
The last note there is more of a point of interest regarding differences between Linux and Windows. In particular, WOW64 works differently than multilib on Linux because on Linux, you can still call int 80h to make syscalls.
On Windows the syscall interface was, I believe, at int 2Eh. It should still work for backwards compatibility reasons, but WOW64 does not rely on it (and presumably, it is one of those things that Microsoft could take away at any time, just like how syscall numbers change and the PEB/TEB structures move around). Exactly what happens for WOW64 syscalls, I'm not sure, because I don't really want to look at disassembly listings for Windows DLLs, so unfortunately my understanding is limited to what things I know from reading books and Raymond Chen. It is quite likely I have some of the details a bit off, no question about that.
64-bit Wine does not require 32-bit components, but traditionally to make a WOW64 Wine build, you need to do a special build process that involves building Wine twice. This is likely where things get murky in terms of packaging, because you can still separate out the two builds of Wine. As far as I know, WOW64 in future versions of Wine will not work this way and shouldn't need 32-bit packages at all.
Unfortunately though I really don't know of a good source regarding the situation and history of it. I am pretty darn sure I saw this discussed on the Wine mailing list before, though.
> WOW64 in future versions of Wine will not work this way and shouldn't need 32-bit packages at all.
Correct, with the “new”/32-bit-code-in-64-bit-process Wow64, there’s an option you pass to ./configure to specify what archs to build the PE DLLs for (i386 and x86_64 for this case)
wow64 itself would have to be a 32 bit library that interacts with 32-bit wine. I don’t believe there’s a way around that. The talk of syscalls seems irrelevant since Wine has to intercept all the syscalls and redirect them to libc, reimplement, or make its own Linux syscall. Being able to do syscalls from 32-bit mode and the back compat of that seems completely irrelevant here.
Clarification: you could actually have Wow64 do IPC to 64-but wine to get rid of the need for a 32-bit wine, but I suspect there’s too much overhead for that, especially since WoW64 would still need to be in 32-bit.
IPC is not necessary: you can in fact jump from 32-bit code to 64-bit code using a special kind of FAR call across code segments! This is what the new Wine-on-Wine64 is doing. I'm mentioning Windows syscalls because Wine implements the Windows syscalls by redirecting them to UNIX libraries, and it happens to be using the same exact idea as how Windows syscalls go from Windows-on-Windows64 for calling 64-bit libraries in Wine-on-Wine64. What is a syscall in Windows is a library call in Wine, and they happen to use a similar mechanism. (I mentioned elsewhere in the thread that I realize this is not a case where things are exactly the same, but it's closer related than I think you're giving it credit.)
As I understand it, the way that AMD64/EM64T processors actually evolved, rather than having completely separate "modes" for real mode/protected mode/long mode, instead, internally, the processors are more-or-less just masking features on and off. So jumping from 32-bit to 64-bit code isn't actually impossible, in fact it's obviously necessary for 32-bit code to be able to make syscalls in the first place, but what might not be clear is that at least on AMD64, you can do this jump purely in usermode, too.
The funny abilities of x86 processors even allow you to mix and match a bit with the different modes; For example, the old Linux x32 ABI[1], or Unreal Mode[2], not to mention the fact that older protected mode OSes (like Win9x) would often thunk to real mode for legacy drivers.
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.
You 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.
The 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.)
When 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.
I'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.)
The 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.
From my research the situation is a bit murkier in that even 64-bit wine seems to require 32-bit components for some reason but that may be a basic packaging issue and the real blocker.
Do you have any supporting links I can read for your claims? I haven’t been able to find anything.