3 ms·

If this documentation is accurate, Darling doesn't support raw syscalls either: https://wiki.darlinghq.org/documentation:system_call_emulation https://wiki.dar

by Tobu 7y ago

If this documentation is accurate, Darling doesn't support raw syscalls either: https://wiki.darlinghq.org/documentation:system_call_emulation https://wiki.darlinghq.org/documentation:system_call_emulati... Their Linux kernel module does seem to be XNU based, but it feels like poor design / a rushed job to run it as a Linux kernel module instead of isolating it in userspace.

LubosD 7y ago
Rushed job? We've been at this for almost 8 years. We tried doing this without a kernel module for several years, but it just wasn't feasible. You see, people think XNU is just another kernel, but it's very different from Linux or the Windows kernel. The only reason why we need a kernel module is Mach IPC. But this IPC is so critical and omni-present that a user-space process cannot even do a sleep() without using it. Even event loops in every GUI application use Mach IPC on the lowest level. There is no way of implementing the full semantics of this IPC mechanism without a help from the kernel. For example, Mach IPC involves making direct memory copies between processes. So even if we decided to take the "wineserver" approach, which would set us back by several years, the result would be super slow and not very compatible. Also the userspace on macOS is quite different from other operating systems, which is why it's all taking us so long. MacOS is a bloated system with a huge number of layers sitting between the UI toolkit and the windowing server. Imagine creating Wine from scratch. How much functionality would you need to implement to provide the correct behavior for a super-simple native GUI application? Probably just USER32, GDI32 and KERNEL32 would do. On MacOS, this is AppKit, QuartzCore, Foundation, CoreFoundation, libobjc and libSystem (which includes huge components such as libdispatch and emulating complex APIs such as kqueue). FYI: The reason why we don't emulate raw syscalls is because this is not possible from kernel modules, unless you resort to techniques that could easily destabilize the whole system.
- yellowapple 7y ago
  While I agree with your overall point (and agree that it's unfair to characterize the hard work y'all have been doing as a "rushed job")... > How much functionality would you need to implement to provide the correct behavior for a super-simple native GUI application? Probably just USER32, GDI32 and KERNEL32 would do. On MacOS, this is AppKit, QuartzCore, Foundation, CoreFoundation, libobjc and libSystem (which includes huge components such as libdispatch and emulating complex APIs such as kqueue). I don't think "number of APIs" is the reasonable benchmark for how difficult it might be to get a GUI application up and running. It's totally possible that macOS might more eagerly split out functionality into different systems while Windows combines that same functionality into relatively few. I don't know how true that is, but it'd be interesting to compare based on the depth of those libraries rather than just the quantity. And from what I understand about Wine, all three of those Windows libraries are incredibly complex and convoluted, and even to this day have gaps in their Wine equivalents. Assuming macOS' greater quantity of necessary libraries add up to the same degree of API surface to be reimplemented, what y'all are doing is impressive, to say the least (and sure, Wine's more usable right now, but Wine also had a decade or two of a head start).

by Tobu 7y ago

LubosD 7y ago

Rushed job? We've been at this for almost 8 years. We tried doing this without a kernel module for several years, but it just wasn't feasible. You see, people think XNU is just another kernel, but it's very different from Linux or the Windows kernel. The only reason why we need a kernel module is Mach IPC. But this IPC is so critical and omni-present that a user-space process cannot even do a sleep() without using it. Even event loops in every GUI application use Mach IPC on the lowest level. There is no way of implementing the full semantics of this IPC mechanism without a help from the kernel. For example, Mach IPC involves making direct memory copies between processes. So even if we decided to take the "wineserver" approach, which would set us back by several years, the result would be super slow and not very compatible. Also the userspace on macOS is quite different from other operating systems, which is why it's all taking us so long. MacOS is a bloated system with a huge number of layers sitting between the UI toolkit and the windowing server. Imagine creating Wine from scratch. How much functionality would you need to implement to provide the correct behavior for a super-simple native GUI application? Probably just USER32, GDI32 and KERNEL32 would do. On MacOS, this is AppKit, QuartzCore, Foundation, CoreFoundation, libobjc and libSystem (which includes huge components such as libdispatch and emulating complex APIs such as kqueue). FYI: The reason why we don't emulate raw syscalls is because this is not possible from kernel modules, unless you resort to techniques that could easily destabilize the whole system.

yellowapple 7y ago
While I agree with your overall point (and agree that it's unfair to characterize the hard work y'all have been doing as a "rushed job")... > How much functionality would you need to implement to provide the correct behavior for a super-simple native GUI application? Probably just USER32, GDI32 and KERNEL32 would do. On MacOS, this is AppKit, QuartzCore, Foundation, CoreFoundation, libobjc and libSystem (which includes huge components such as libdispatch and emulating complex APIs such as kqueue). I don't think "number of APIs" is the reasonable benchmark for how difficult it might be to get a GUI application up and running. It's totally possible that macOS might more eagerly split out functionality into different systems while Windows combines that same functionality into relatively few. I don't know how true that is, but it'd be interesting to compare based on the depth of those libraries rather than just the quantity. And from what I understand about Wine, all three of those Windows libraries are incredibly complex and convoluted, and even to this day have gaps in their Wine equivalents. Assuming macOS' greater quantity of necessary libraries add up to the same degree of API surface to be reimplemented, what y'all are doing is impressive, to say the least (and sure, Wine's more usable right now, but Wine also had a decade or two of a head start).