search

darlinghq / darling

Darwin/macOS emulation layer for Linux
http://www.darlinghq.org
GNU General Public License v3.0
11.37k stars 441 forks source link

Sugestion: PowerPC (and ARM) emulation support #252

Open Arucard1983 opened 7 years ago

Arucard1983 commented 7 years ago

Although is a little early to implement the "Darling Rosetta", since the Appkit support is highly experimental, and command line utilities are ports from Linux programs, one of the target uses of Darling use may to run old Mac OS X programs coded for the Power PC architecture.

So far, there's two ways to achieve this functionality:

  1. Get the Qemu User Module (qemu-ppc-static for the 32-bit PowerPC programs, and qemu-ppc64-static for 64-bit ones), and Darling will load this program, along the Darling components compiled for the PowerPC. This means, we will have a DPREFIX for x86, and another for ppc, unless the Darling itself manage to recognize.

  2. Get the PearPC CPU core emulator, and port to Darling.

    I think the first approach is more easy to achieve, and won't require much effort to implement.

LubosD commented 7 years ago

qemu user emulation could work for sure and you probably wouldn't need a different prefix - thanks to FAT Mach-O binaries being used for the prefix (which is a work in progress).

The real question is if there are still any PPC Mac OS X applications that were never ported to x86 and are worth while.

Arucard1983 commented 7 years ago

And the same strategy can be applied to the iOS ARM programs. So far, by my experience, I use the Qemu-User-Mode on one ARM computer to run the "rar" utility to create RAR archives, since it was released for x86 Linux only, and I use this little emulator to run "rar", and a very few GTK programs. Also the binfmt_misc module simplify the program management, since PowerPC, ARM and x86 programs can be called from the Darling without effort, since the adequate emulator are loaded and executed directly.

But the main issue is how the Darling executable, when execute PPC code using qemu-ppc-static, the PPC OS X program makes a system call to the Mach API, where, so far I know, are implemented as a Linux kernel module. Qemu not support kernel modules, which could give two scenarios:

  1. If a PPC program makes a direct Mach API system-call, Darling will kill the program. And this is how Rosetta handles PPC code, since many extensions, Java applets, kernel modules was not compatible.

  2. If a PPC program makes a direct system call as before, a patched qemu-ppc-static or a special Darling routine will translate some system calls to the native x86 Mach module, as long it is possible, otherwise the program is also killed.

    Realistically, very few PPC OS X programs are worth to try, and much of them are old versions of Microsoft Office or Quicken. Some of them, like the PPC Quicken use file formats and functionalities that was made incompatible to the x86 Quicken. Also, some old PPC software had features that was crippled to the most recent ones. Even so, the PPC support to Darling may be comparable to the 16-bit Windows support on Wine. In most cases, most Wine users don't even run Windows 3.x programs, but some do. The same could be applied to Darling.

bugaevc commented 7 years ago

qemu user emulation could work for sure

It won't, because we link to native libraries; unless you're suggesting users should install PPC versions of their whole /lib.

If a PPC program makes a direct Mach API system-call, Darling will kill the program.

"Good" (see #193) macOS programs only use syscalls and Mach traps via library wrappers; this is how syscall emulation works on Darling. Mach traps are implemented as ioctls on /dev/mach, so this won't be a problem.

grepwood commented 4 years ago

What about running Darling on a PowerPC host? There are some games released for OSX that could be played on Linux PPC if Linux supported OSX binaries. With Darling, that possibility is open.

CuriousTommy commented 4 years ago

It could be done, but someone would just have to be interested in doing it. I am currently trying to get darling to build on an ARM64 device.

Arucard1983 commented 4 years ago

After some real adventuring on programming, I think that the "Darling Rosetta" will require to the user install:

  1. Enable the ppc and ppc64 multilib repositories, in order to install native library dependencies, including OpenGL, Vulkan (unlikely), several core libraries (GIF, TIFF, etc), and other things.
  2. Install Qemu-User-Static package, that will configure the Linux computer to load user-mode programs compiled to non-x86 architectures.
  3. Darling needs some changes to support ppc and ppc64 binaries, and then load the correct libraries. The Qemu will be loaded automatically due to the binfmt_misc kernel module.

Honestly I think that a Darling Setup applet (Like the winecfg) would be the first thing to do, to help novice users to configure some features.

Arucard1983 commented 4 years ago

I was wandering with old PowerPC software that works on Mac OS 9 and earlier Mac OS X to find a real motivation to someday implement the "Rosetta", and I notice that any real use to introduce PowerPC emulation to Darling are 99.9% certain that the old software are games.

But the real problem of the earlier Mac OS X games are actually Mac OS 9 software (PEF executable) and run on real Mac OS X using the Classic Environment, which gives another headache.

So far the only project similar to Wine and Darling dedicated to run Mac OS Classic software was the Ardi's Executor, and an active fork named Executor 2000 was made some improvements, including PowerPC emulation which are highly experimental so far. (The old 68K emulation mode are still there). Maybe on the future the Executor 2000 starts to implement the later Mac OS 9 libraries, or at least the minimum support to run old games, and then integrate on Darling for "Legacy Support".

grepwood commented 4 years ago

What about the no-emulation approach like with Wine? Wine does not emulate x86/amd64 in a normal setup but instead delegates Windows library calls to Wine subsystems that hook up nicely into native backends, regardless if the host OS is OSX, Linux or *BSD. This is exactly the kind of support I'm looking for with regards to PowerPC software because I have a big-endian PowerPC machine with AltiVec support. In theory, this is a basic foundation with which a Wine-like API wrapper could work relatively fast.

LubosD commented 4 years ago

@grepwood We don't have that hardware and neither do 99.9% of others, so emulation will be the primary way to go.

@Arucard1983 PEF executables are not a problem (easy to implement) and a lot of them could have been executed under macOS without using the Classic Environment. The Classic Environment was aimed at non-CarbonLib CFM (PEF) software.

non-CarbonLib stuff is really better left to Executor 2000.

grepwood commented 4 years ago

@LubosD sorry to hear that. Just a heads up - PS3s, G5 Macs and Wii Us are still out there on eBay.

Arucard1983 commented 4 years ago

Now Apple introduce macOS 11.0 Big Sur with native aarch64 support (Arm 64-bit). With this, Darling really need to support arm and powerpc builds coupled with Qemu User Mode.

Arucard1983 commented 3 years ago

Combining the ideas shared on this discussion, I think that this feature will need the following realistic milestones (Edit):

  1. Enabled support to compile Darling's frameworks for ARM and PowerPC (which is partially under way.)
  2. Combine Qemu Static User emulator to Darling load PowerPC and ARM binaries, either 32 or 64-bit (still Power PC G5 binaries are rare on Mac OS X.)
  3. Testing PowerPC or ARM programs. More than 90% of such software on realistic terms would be games.
  4. As sugested by @LubosD, implemented PEF executable support that enables to run Carbon programs that run either on Mac OS 9 (and later 8.x) or the earlier Mac OS X version. Either cases are 32-bit Power PC binaries.
  5. If necessary implement a CarbonLib wrapper over the Darling's Carbon libraries (that are also wrappers around the Cocoa and other stuff, including QuickTime, QuickDraw and Audio), to make some Mac OS 9 software running on Darling. Still, more than 99% of potential software would be games. Productivity software, extensions, browsers or everything for such old platform are better to not bother at all. Support for OpenGL for PEF executables implemented as a wrapper could be another addition.
  6. Essentially, instead to create a Classic app (like the Classic Environment on Mac OS X) to run the PEF executables (games), a better approach was a Wine-like method. All PEF programs would run attached to a loader/server program (in a way that Win16 programs runs on Wine using winevdm) that makes a quick emulation of the ancient operating system, and passes all system calls to the Darling's native libraries. With this, old programs would behave like the newer ones.
grepwood commented 3 years ago

@Arucard1983 as for number 1, if I can help it, I can either lend my PS3 for development or sponsor a G5 for someone who can drive this. Native PowerPC support a'la Wine's non-emulating support for x86 on x86 hardware would be very desirable for other weirdos like me who still hold on to big endian PowerPC hardware.

Arucard1983 commented 3 years ago

As an additional remark about those milestones: PEF PowerPC executables would run always on a preemptive and protected multitasking environment. A native or Mach-O binary (using Qemu for x86 hosts) called pefserver (or whatever named) emulate some flags and stubs for Mac OS 9 and Mac OS X support, and loads the wrapper compability libraries for CarbonLib and GLLib against the Darling's frameworks that was based. The perserver then starts a pefclient for each PEF executable and handles the Mac OS 9 emulation shims when the program requested. If the PEF natively supports Mac OS X libraries, it will be accepted by default, and only fallback for Mac OS 9 emulation when the program don't support it. However, as explained before, the focus would be games and simple programs. The advantage of this approach was the removal of the obsolete 68k software traps, lesser RAM usage by avoiding a full Mac OS 9 virtual machine. Software that require specific extensions, that was enhanced the old Mac OS 9,or been plug-ins or system extensions or control panels, or use 68k code would left unsupported and killed for good. Eventually, additional wrapper for printing could be considered, but the printing request would be pass to native CUPS, instead on the original classic, that uses Mac OS 9 drivers inside Classic just for printing!

Arucard1983 commented 3 years ago

I found on GitHub a (unfortunately) abandoned project that precisely would implemented the #4 and #5 features: Classix. https://github.com/zneak/classix

This was intended to run PowerPC PEF executables of the Mac OS 9 era using a compatibility layer that implement some Classic libraries over the Mac OS X frameworks. The project included a PowerPC binary translator emulator to run on Intel machines. My humble suggestion is someday to fork this project and integrate to Darling, just in case to run old PowerPC games that could run on OS X or Mac OS 9 that require some libraries of the older operating system to run.

My other hand, a potential list to test the Darling's PEF support would be:

Diablo II & Lord of Destruction Age of Empires II (MacSoft port) Microsoft Office 2001, X and 2004 (both are PEF executables with Carbon support.) ... (fill a game with native OpenGL support)

grepwood commented 3 years ago

@Arucard1983 you can try WarCraft 3 if you have the original iso lying around. Blizzard's last patch that had PowerMac support was 1.26a IIRC

mePy2 commented 3 years ago

@Arucard1983 @grepwood PM me on Discord mePy2#0741

grepwood commented 3 years ago

@mePy2 sent you a friend request.

wyatt8740 commented 3 years ago

What about running Darling on a PowerPC host? There are some games released for OSX that could be played on Linux PPC if Linux supported OSX binaries. With Darling, that possibility is open.

This could be handy for things like Flash games on PPC Linux. Adobe made a stand-alone player/projector up to 10.1.102.64 for PPC OS X, but never made a publicly available PPC Linux build. Emulating the x86 ones in qemu is quite painful.

grepwood commented 3 years ago

@wyatt8740 at this point I'm more inclined to wait for a proper FLOSS Flash replacement to arrive. Here's a quick rundown of the Flash situation I mailed a while ago:

monyarm commented 3 years ago

There's also Ruffle, a flash emulator written in rust, last time i tried it was half a year ago, and i was able to run some simple swf animations and games on it.

wyatt8740 commented 3 years ago

@wyatt8740 at this point I'm more inclined to wait for a proper FLOSS Flash replacement to arrive. Here's a quick rundown of the Flash situation I mailed a while ago: …

Yeah, I am largely in agreement there. Especially the part about Mozilla.

Ruffle worked pretty well for a lot of things – though unfortunately, the desktop version currently requires a Vulkan renderer which lots of machines (including power macs) don't have without falling back on software rendering implementations. Gnash (while abandoned) works quite well for older flashes, but is getting harder and harder to build all the time. It's probably just one or two more FFmpeg API breakages away from me giving up on it.

Lightspark… is interesting, but still flawed in some major ways, and prone to segfaulting in my experiences with it. Also, it has some endian problems that cause incorrect colours on PowerPC as well.

grepwood commented 3 years ago

lots of machines (including power macs) don't have without falling back on software rendering implementations

PowerMacs IIRC come in variety of shapes and sizes. Some with integrated graphics, some not. We know PowerMacs like IBM PCs have PCI, AGP and PCIE ports, so it shouldn't be a problem to: