Future of Darling

[andyneff]

My subject matter expert tells me Apple is going to eventually move to ARM64 only support for their OS (and apps). With Roseta 2 allowing them to run x64 on arm64 via emulation.

My question is what does this mean for darling moving forward?

• Will darling continue?
• Will darling only ever run x86_32/x84_64 apps?
• Will darling eventually run arm64 apps?
• Will it be in an arm emulator or use one?
• Will there still be an LKM?

Related: #642 #352

[bugaevc]

Darling will definitely continue — at least as a way to run x86_64 (or x86) binaries on x86_64 Linux systems. We also want to get arm64-on-arm64 binaries working (but not there yet).

Then, there's emulation. We're not going to implement a complete emulation solution from scratch, so the potential Darling Rosetta would be based on an existing emulator — usermode QEMU. We've been envisioning a bright distant future where Darling is able to run binaries for either ppc/ppc64/x86/x64/arm64 on either of those architectures, using Darling Rosetta if the host and the program architecture don't match. But we're probably far away from that. Just arm64 on x64 is fairly possible though, but we have to get native arm64 on arm64 working first.

[CuriousTommy]

Will darling eventually run arm64 apps?

@andyneff I was working on adding ARM64 support (feature/arm-support branch), but I am putting it on hold for the time being since the XNU kernel needs to updated. Because @facekapow is doing a huge update to all of the open-source Apple code we use (update-sources branch), I rather have him deal with updating the kernel.

I personally do want Darling to support arm64 apps. Having MacOS arm64 apps working on Linux ARM64 devices will greatly benefit Linux.

[Arucard1983]

By other hand, support to run PowerPC binaries, specially the PEF binaries are also an important addition. The latter format are used by several programs and games on Mac OS 9 and earlier Mac OS X era, which are used by Carbon programs (using the CarbonLib and InterfaceLib on Mac OS 9, that many functions are implemented on CoreServices).

I discovered that someone tried to implement a similar project like this to run some Mac OS 9 programs called Classix, but the development was stalled.
https://github.com/zneak/classix

This project could be merged as darling-classix, since it could make some Mac OS 9 programs (mostly games) running on Darling, since all classic libraries are wrappers to Darling's frameworks. Still it could be required to implement OpenTransport, OpenGL and Game Sprockets to make more useful (as many games requires to run.)
A CarbonLib wrapper could be done in a similar way.
Old and really ancient Mac OS software for 68K are unsupported on Classix, and better served to the M.A.C.E. and Executor 2000 emulators.
Panel Controls and Extensions are also unsupported, or within a restricted functionality to make the target program work, as long are pure user-mode software.
With this setup, it avoids to run a full emulator with a full copy on Mac OS 9, where all programs runs without real memory protection and had limited multitasking (not forgetting the PPC/68K emulation overhead required to several syscalls!).
With Classix, every Mac OS 9 program runs on a separate process and memory space, make them more stable than the original operating system. This could break some functionalities (specially productivity programs that share memory with other software), but it can be minimized using pipes, or not bother at all, since any eventual Mac OS 9 support on Darling would be limited. Many games (the target 99% of real world uses) would simply run happily on their own protected memory space.

The program itself uses a native Mach-O program (classix) that loads the PEF executable, and then the wrappers libraries (or native libraries that depends from the core wrappers), to make it work. Like Darling, Classix never finishes the GUI workings adequately, but the author intended to use the native Cocoa's bindings as possible, making all old programs "modernized".
Classix contains a PowerPC binary emulated forked form Dophin emulator, but it could be replaced by another one, or by Qemu User Mode.

If Classix would be merged to Darling (and can be implemented on their own repository), to support PEF binaries, it may be a supplemental bonus to bring back old games running on modern systems. Diablo II or Quake III MAc versions running on Linux using Darling would be nice. Micorsoft Office 2001, X or 2004 in a similar way could be another test (even partially working.)

[Adyan424]

if u guys are able to port darling to arm64 will that enable ios app support ?

[facekapow]

Not automatically, no. iOS has quite a number of differences with macOS (mainly in the higher level libraries like UIKit), but getting ARM64 support would be a significant step towards iOS support.

[Adyan424]

Also whats apps are compatible as of writing.I mean GUI apps not CLI and how much time will it take to support big ones like final cut and logic pro x.

[Zegute]

Also whats apps are compatible as of writing.I mean GUI apps not CLI and how much time will it take to support big ones like final cut and logic pro x.

I want Darling have a GUI, such like Early Mac OS X. In some case, Darling need add chroot(it has, but running on overlay fs),
switch_root and encrypt hfs make, read, write support, because I'm building a linux distro. And Minimize dependency on procfs.

[Adyan424]

Also whats apps are compatible as of writing.I mean GUI apps not CLI and how much time will it take to support big ones like final cut and logic pro x.

I want Darling have a GUI, such like Early Mac OS X. In some case, Darling need add chroot(it has, but running on overlay fs),
switch_root and encrypt hfs make, read, write support, because I'm building a linux distro. And Minimize dependency on procfs.

yeah u are right big sur sucks and i wish they add apfs support in future.

[Zegute]

Also whats apps are compatible as of writing.I mean GUI apps not CLI and how much time will it take to support big ones like final cut and logic pro x.

I want Darling have a GUI, such like Early Mac OS X. In some case, Darling need add chroot(it has, but running on overlay fs),
switch_root and encrypt hfs make, read, write support, because I'm building a linux distro. And Minimize dependency on procfs.

yeah u are right big sur sucks and i wish they add apfs support in future.

Oh, i hope it has a GUI App Builder, it's easy to build a program. The Mona OS
The sandbox is easy to help ours data...

[CuriousTommy]

Darling need add chroot(it has, but running on overlay fs)

In the past, Darling was set up to use chroot (without overlay fs), but it was more trouble than it was worth.

[Zegute]

Darling need add chroot(it has, but running on overlay fs)

In the past, Darling was set up to use chroot (without overlay fs), but it was more trouble than it was worth.
So, how to set up to use chroot without overlay fs?
Could Darling add kext support and kextcache?

[CuriousTommy]

Darling will only provide support for user space, kernel space stuff (like kext) are not supported.

[Zegute]

Darling will only provide support for user space, kernel space stuff (like kext) are not supported.

So, Darling need to add a thing can connect kernel space(that's like mixed OS), like kmodutils(the questions are how to run kext and etc.)

[Zegute]

Darling will only provide support for user space, kernel space stuff (like kext) are not supported.

Darling need add devfs(like BSD's devfs, uuid and volume name supports)
Beacuse the f**king udev is so......

[Zegute]

Darling need add chroot(it has, but running on overlay fs)

In the past, Darling was set up to use chroot (without overlay fs), but it was more trouble than it was worth.

I also need a pivot_root function.

[digital-pers0n]

What about Metal? Would it be possible to make Metal.framework on top of Vulkan?

[leap0x7b]

Then, there's emulation. We're not going to implement a complete emulation solution from scratch, so the potential Darling Rosetta would be based on an existing emulator — usermode QEMU.

I found @ptitSeb's Box64 have better performance than usermode QEMU and it's performance is near Rosetta 2 level of performance (https://box86.org/2022/03/box86-box64-vs-qemu-vs-fex-vs-rosetta2/) so we probably can use Box64 as a base instead of usermode QEMU

[leap0x7b]

Box86 which is made by the same author that made Box64 can be optionally used if you want x86-on-arm64 (if armv7 libraries were installed) and x86-on-armv7 emulation

[madscientist159]

Any chance of getting ppc64/OSX on ppc64/Linux emulation working, e.g. on the Talos II machines? If the architecture matches, is most of the codebase agnostic (no significant hand-coded assembly)?

If there's interest, I'm happy to provide access to a machine. I'd love to see UT2004 working...

Thanks!

[kristibektashi]

Here's an interesting idea: Porting Darling to macOS and using it to run 32-bit x86 apps in newer macOS versions that don't support them natively (and even on Apple Silicon)

[HinTak]

@madscientist159 I remember that earlier ppc mac os x actually works quite well with qemu. FWIW.

[upintheairsheep]

Darling will definitely continue — at least as a way to run x86_64 (or x86) binaries on x86_64 Linux systems. We also want to get arm64-on-arm64 binaries working (but not there yet).

Then, there's emulation. We're not going to implement a complete emulation solution from scratch, so the potential Darling Rosetta would be based on an existing emulator — usermode QEMU. We've been envisioning a bright distant future where Darling is able to run binaries for either ppc/ppc64/x86/x64/arm64 on either of those architectures, using Darling Rosetta if the host and the program architecture don't match. But we're probably far away from that. Just arm64 on x64 is fairly possible though, but we have to get native arm64 on arm64 working first.

arm32 should be considered as well for old iOS apps, and ppc64 was never used for macOS nor iOS to my knowlege.

[CuriousTommy]

ppc64 was never used for macOS nor iOS to my knowlege.

Actually, the G5 is ppc64: https://en.wikipedia.org/wiki/Power_Mac_G5

[upintheairsheep]

Not automatically, no. iOS has quite a number of differences with macOS (mainly in the higher level libraries like UIKit), but getting ARM64 support would be a significant step towards iOS support.

WinObjC implementations would have to be "brought in" to Darling first, as well as some borrowing from touchHLE.

[merryhime]

Hi, there are some modern alternatives to QEMU:

• FEXCore provides fast user-mode emulation of x86-64 on AArch64 (notably used by Steam's Proton).
• dynarmic provides fast user-mode emulation of AArch64 on x86-64 (notably used by touchHLE as well as several other emulators for modern AArch64 consoles).

Evidently I am biased as I am the author of dynarmic, but I'm quite willing to assist in integration.

[ptitSeb]

Hi, there are some modern alternatives to QEMU:

• FEXCore provides fast user-mode emulation of x86-64 on AArch64 (notably used by Steam's Proton).

Were did you see FEX is used in Steam's proton?

[merryhime]

Misunderstanding on my part - from memory the FEX team had previously contributed to Proton/pressure-vessel to enable running under an emulated/multi-arch environment and I had conflated the two - apologies!