4 ms·

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 Linu

by jchw 3y ago

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.

mrpippy 3y ago
> 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)
vlovich123 3y ago
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.
- jchw 3y ago
  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. [1]: https://en.wikipedia.org/wiki/X32_ABI https://en.wikipedia.org/wiki/X32_ABI [2]: https://en.wikipedia.org/wiki/Unreal_mode https://en.wikipedia.org/wiki/Unreal_mode

by jchw 3y ago

mrpippy 3y ago

> 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)

vlovich123 3y ago

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.

jchw 3y ago
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. [1]: https://en.wikipedia.org/wiki/X32_ABI https://en.wikipedia.org/wiki/X32_ABI [2]: https://en.wikipedia.org/wiki/Unreal_mode https://en.wikipedia.org/wiki/Unreal_mode