I heard that QEMU has some support for user-mode emulation on OS X. I also heard that it is very buggy. Has anyone tried to use it? Is there any place to download betas? Are there any apps that work?

I haven't tried it, although I've been wondering about it recently. It would be interesting, for example, to wrap Classic in qemu or even do an integrated desktop.

I would expect it to be very buggy, as all sorts of library dependencies exist under PPC OS X that would need to be accounted for.

Downloading at this point consists of grabbing the source tree off github and compiling it against the user-mode target. Right now we're still working on improving the virtual machine builds.

You mean compiling qemu for ppc on ppc OSX?

I was just working on that today. It seems it uses something called the tcg interpreter which is experimental. I got as far a completing a build that starts, but not with cocoa. And gtk/sdl seem to dependent on X in a way that creates errors I haven't been able to fix.

Best,
Cat_7

One thing to note from the TCG docs:
"* Floating point types are not supported yet"

This means it'll still be using softfloat for FPU emulation, which, as we've recently discovered, may be accurate, but is extremely slow.

That's not what I meant at all. I meant the processor-only emulation(running powerpc apps on intel or vice versa, like rosetta).

Something more like this then, which means not having to bother with the OS and just run the apps made for that OS. I haven't tried it out the user emulation at all. I've more or less been running the OSes directly, then running the apps in those OSes rather than running them in QEMU.

I don't think this would work unless you were running PowerPC apps compiled for OS X 10.4 or 10.5 PPC on OS X 10.4 or 10.5 Intel. Otherwise, the libraries wouldn't match, as I commented earlier. Usermode emulation assumes that the architecture is the same but the processor has changed -- but later OS X versions would have differently behaving API calls and slightly different libraries, meaning that the translation of the PPC instructions wouldn't be enough to get the software to run. It might work for BSD-level MachO binaries (assuming the libraries haven't changed too much on your host system or you've got MacPorts installed), but won't likely work for application bundles.

Aren't application bundles somewhat(or mostly) version-agnostic. Netscape Navigator 9.0.0.6 can run on OS X 10.2-OS X 10.11(the only errors are that you need a legacy JRE, and that's about as much of a problem as X11). Well-written apps usually don't stop working after an update, since apple's backwards compatibility is(was as far as processor emulation and backwards compatibility with pre-"reboot" versions["reboot" for windows is NT, for mac, it's OS X], but that has changed with windows, too) good(but not nearly as good as windows'[up until XP, that is]).

I think that user-mode emulation is more promising that virtual machine as far as "double click to run" app bundles are(like winebottler packages windows .exe files into mac .app bundles).

Ahh... but userland qemu is only like the WINE core; it doesn't know about APIs, so you need to install all the support libraries as well. WINE is all about re-implementing the core APIs so that you don't have to do this. And of course, WINEBottler and WineSkin work by taking a full implementation of WINE, adding the file structure of a Windows environment, adding in the extra libraries (that aren't hardware dependent), and then bundling that up with a display environment.

This is definitely possible with qemu, but we're a long way from that, and there's been no API reimplementation done, so a lot more of the core OS would have to be included -- likely running into copyright issues.

[edit] and I should probably point out that WINE is not an emulator It depends on the host OS having the same instruction set to work with as the bundled binaries... only the APIs are missing, and it reimplements these from scratch.

It should be possible to jump-start something like WINE for OS X using Darwin, OpenStep and DisplayPDF as a starting point, and distilling that down, then creating a generic interface with kernel-level operations. But that's an ever-moving target with OS X, and that project, to my knowledge, hasn't even been started.

The wine core takes windows format executables and creates host OS formatted executables. The APIs that are not part of the host OS are then added with the full implementation. OS X 10.11 has more APIs in common with OS X 10.0 then it will ever have with windows, so some APIs will not even need to be re-implemented. QEMU user mode emulation takes an executable that uses a different processor and converts it to use the processor of the host.


I know that they do that. I was thinking that apps that use APIs that are still included in modern OS X can be translated with QEMU user mode, and even bundled with it to make it work as an app bundle(like winebottler).


True, and I know that. I think there was a project, darwine, that used an x86 emulator and wine to run windows applications on PowerPC. The only part of vanilla wine that can be considered an emulator is the conversion from windows binaries to host OS binaries, but that's simulating an API, not emulating hardware.


You're thinking of wine on OS X or wine on Linux. I'm thinking more like wine on 64-bit windows for the VDM. It might be useful for 16 bit programs, but a modified DOSBOX that catches the DOS functions and forwards the windows functions to windows. QEMU used like rosetta. That would work for apps that use non OS X version specific APIs. Apple deprecates APIs, but rarely removes them(for example CarbonLib is still in OS X even though it was originally for OS 9[it's deprecated and 32 bit only, though]).

You raise a few really good points here; the one that seems most interesting to me actually has to do with CarbonLib: qemu could definitely be used with any carbon-clean software. We'd still need to deal with endianness issues in some places, but Apple managed to do that, so there shouldn't be too many in carbon/MachO binaries.

So now all we need is a dedicated group of individuals to do the heavy lifting of making it happen I have to admit that my focus is more on preserving old operating system environments than in making old software run natively on new OSes, but there are definitely some titles out there that could benefit from this.

...And if completed, the only thing left to do that can make a huge amount of software run on modern OS X is a port of User Mode linux(or something similar), which wouldn't require as much work, since it is almost all open source(OS X is <50% open source and windows is not open source at all), and the stuff that is not open source is mostly drivers and low level stuff that isn't necessary to run software.

Why not just use MacPorts or Homebrew? Most of KDE and Unity already run on OS X; it's kernel-dependent stuff like KDE that doesn't, and for that you just run Linux in a VM. The benefits of Open Source are that you can compile the software to run natively.

http://softpear.sourceforge.net/
Maybe this project can help. But it seems that this project is no longer under development.

And has more bugs than I can handle right now, but it is the kind of thing I was talking about.

If that was the OS X page, it would be exactly what I'm talking about , but it doesn't yet run on mac os x.

Can you do that on OS X? I tried configuring it with this:

To install it in my home directory(compiling it with macports-also installed in my home directory with --with-no-root-privileges ). It only compiled , , and . Do I need to enable/disable more stuff(probably only enable, since I disabled almost everything)?

Also, Is there a cleaner way to set off snippets of code-related stuff than the code tags?

Is there a special target for usermode emulation on OS X or some extra patches you need to install? It says you can have usermode emulation on linux or BSD, but it doesn't say anything about OS X. I know code for it exists, but I don't know how to enable it. I'm just trying to build the existing code right now. I'm not trying to add new code.

Check the BSD config and makefile details; I didn't see much about it when I was rooting through there, but it must be in there somewhere.

There are BSD usermode QEMU, but they are just x86 and SPARC. I think that at some point there was either a Darwin usermode QEMU, or an offshoot of QEMU that had a Darwin usermode. I don't know what happened to it, though.

A quick google brought up the --enable-darwin-user configure flag. Seems like --enable-guest-base would likely be needed too.

In a few other places, it appears that this is specifically for running usermode in darwin with X, not for OS X via Aqua UI.

It looks like it hasn't been maintained for at least 8 years and was removed from the code base 4 years ago. I think modernizing can be done, but it would have to start with version QEMU 0.90 or 1.0 because that looks like the last time darwin usermode was enabled. I forked a QEMU 0.90 repository in GITHUB at https://github.com/JustinCB/qemu, and I'll try to do a little work on it, but don't be surprised if I don't get very far. I still need to fix this error:
dyngen.c:1955:2: error: darwin x86_64 host not implemented yet
#error darwin x86_64 host not implemented yet



That errror is better that these:



dyngen.c:1931:46: error: no member named 'r_info' in 'struct relocation_info'
type = ELF32_R_TYPE(rel->r_info);
~~~ ^
dyngen.c:1932:35: error: no member named 'r_addend' in 'struct relocation_info'
addend = rel->r_addend;
~~~ ^
dyngen.c:1933:41: error: no member named 'r_offset' in 'struct relocation_info'
reloc_offset = rel->r_offset - start_offset;
~~~ ^
dyngen.c:1935:26: error: use of undeclared identifier 'R_X86_64_32'
case R_X86_64_32:
^
dyngen.c:1939:26: error: use of undeclared identifier 'R_X86_64_32S'
case R_X86_64_32S:
^
dyngen.c:1943:26: error: use of undeclared identifier 'R_X86_64_PC32'
case R_X86_64_PC32:


Which I was getting before. If you're interested, I can add you as a collaborator on github.

Would this allow the classic environment that was in Mac OS X up to 10.4 to work on intel versions of Mac OS X?

It would be awesome to be able to finally run the Macintosh version of Visual FoxPro on my new Mac in an integrated environment.

I haven't done much on it. I am really trying to get other people who want to work on it, but I haven't gotten much interest. I also have tried to start off a pearpc based user mode emulator(the thread I started is at viewtopic.php?f=25&t=9207 ). It would be possible to have classic emulation, but It wouldn't be a copy of mac os 9 running in the background with everything except the application windows and sometimes the title bar showing, like in OS X. I want to have(but probably won't be able to get without a lot of people interested) an emulator that links CarbonLib to the classic apps and also uses some code from Executor. If I and any collaborators managed to do it, it would probably be more seamless than classic emulation in OS X.

Has any thought been put into using SDL/X instead of Aqua as the WM for this project? Because it seems to me that if you draw the OS 9 windows direct to X, then managing what does and doesn't get drawn would be significantly easier (just don't draw the desktop "window"). It would also enable the desktop to be enabled/disabled, so that you could use non-integrated mode if you mess something up and need to fix it. Plus, the result could be integrated to any OS that includes an X server.

interesting idea. To bad I don't really know anything about programming though.