4 ms·

> Plenty of other pieces of software such as WINE only work when 32-bit libraries are installed on a 64-bit system. Funny to mention Wine specifically; they're

by jchw 3y ago

> Plenty of other pieces of software such as WINE only work when 32-bit libraries are installed on a 64-bit system. Funny to mention Wine specifically; they're implementing a more sophisticated Wine-on-Wine64 setup that, among other things, will make having 32-bit system libs unnecessary, through the power of Heaven's Gate, not unlike how Windows handles syscalls in real WoW64. (As far as I understand it, Linux, having a stable syscall interface, just supports the old software interrupts for 32-bit syscalls, making this unnecessary. In fact, they seem to even work from a 64-bit process to some degree.)

hef19898 3y ago
I had some weird issues with Ubuntu 22.04, the OEM Steam Installer and some missing 32-bit library. Steam required it, everytime I tried to install it it broke somethong, mostly WiFi. No idea why, and I am no expert, not even close.
Dalewyn 3y ago
>will make having 32-bit system libs unnecessary, ... , not unlike how Windows handles syscalls in real WoW64. WoW64 literally has an entire 32-bit equivalent to Windows's native 64-bit libraries and binaries.
- jchw 3y ago
  I should've known better than to be vague here. I'm talking about just syscalls. Windows differs from Linux in that Windows doesn't have backwards compatibility for the kernel ABI but the userspace ABI; all of the syscalls HAVE to be dispatched by NTDLL, because the syscall numbers are not stable between kernel versions anyway. (Not that this entirely stops crapware like anti-cheat from doing so, but nonetheless.) From my point of view, the closest Wine equivalent of a "syscall" would be calling out to UNIX system libraries, so it does bear some similarities even if it's not quite the same. I don't personally want to open WOW64 NTDLL in IDA because doing so would probably limit me from contributing to Wine, but my understanding is that WOW64 NTDLL is just thunks to Win64 NTDLL, using an intermediate library (one of the wow64*.dlls presumably?) to perform a Heaven's Gate call into the 64-bit NTDLL.
  - AshamedCaptain 3y ago
    Not even that is true anymore since some Windows games are now hardcoding system call numbers.
    - yrro 3y ago
      Why in god's name!?
      - jchw 3y ago
        It's mainly going to be anti-cheat and DRM trying to be tricky and mitigate hooks and obfuscate their behavior.
  - sapphyrus 3y ago
    WOW64 syscalls are indeed implemented using heaven's gate, the 32-bit ntdll calls into a "wow64cpu.dll" module, which does the long-mode transition and ends up calling into the 64-bit ntdll. Unfortunately manual syscalls are still possible (and widely used) on windows, either by hardcoding syscall IDs for common versions or performing very rudimentary "disassembling" of the ntdll syscall stubs.
  - Dwedit 3y ago
    Syscalls aren't just dispatched by NTDLL, they're also dispatched by "Win32u.dll". In earlier versions of Windows, "User32.dll" also makes system calls as well.
    - jchw 3y ago
      Okay, I genuinely did not know that User32.dll made syscalls directly. Interesting, and kind of bizarre.
vlovich123 3y ago
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.
- 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)

by jchw 3y ago

hef19898 3y ago

I had some weird issues with Ubuntu 22.04, the OEM Steam Installer and some missing 32-bit library. Steam required it, everytime I tried to install it it broke somethong, mostly WiFi. No idea why, and I am no expert, not even close.

Dalewyn 3y ago

>will make having 32-bit system libs unnecessary, ... , not unlike how Windows handles syscalls in real WoW64. WoW64 literally has an entire 32-bit equivalent to Windows's native 64-bit libraries and binaries.

jchw 3y ago
I should've known better than to be vague here. I'm talking about just syscalls. Windows differs from Linux in that Windows doesn't have backwards compatibility for the kernel ABI but the userspace ABI; all of the syscalls HAVE to be dispatched by NTDLL, because the syscall numbers are not stable between kernel versions anyway. (Not that this entirely stops crapware like anti-cheat from doing so, but nonetheless.) From my point of view, the closest Wine equivalent of a "syscall" would be calling out to UNIX system libraries, so it does bear some similarities even if it's not quite the same. I don't personally want to open WOW64 NTDLL in IDA because doing so would probably limit me from contributing to Wine, but my understanding is that WOW64 NTDLL is just thunks to Win64 NTDLL, using an intermediate library (one of the wow64*.dlls presumably?) to perform a Heaven's Gate call into the 64-bit NTDLL.
- AshamedCaptain 3y ago
  Not even that is true anymore since some Windows games are now hardcoding system call numbers.
  - yrro 3y ago
    Why in god's name!?
    - jchw 3y ago
      It's mainly going to be anti-cheat and DRM trying to be tricky and mitigate hooks and obfuscate their behavior.
- sapphyrus 3y ago
  WOW64 syscalls are indeed implemented using heaven's gate, the 32-bit ntdll calls into a "wow64cpu.dll" module, which does the long-mode transition and ends up calling into the 64-bit ntdll. Unfortunately manual syscalls are still possible (and widely used) on windows, either by hardcoding syscall IDs for common versions or performing very rudimentary "disassembling" of the ntdll syscall stubs.
- Dwedit 3y ago
  Syscalls aren't just dispatched by NTDLL, they're also dispatched by "Win32u.dll". In earlier versions of Windows, "User32.dll" also makes system calls as well.
  - jchw 3y ago
    Okay, I genuinely did not know that User32.dll made syscalls directly. Interesting, and kind of bizarre.

vlovich123 3y ago

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.

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)