Date: Mon, 24 Nov 2008 00:21:33 -0500 From: Mike Meyer <mwm-keyword-freebsdhackers2.e313df@mired.org> To: Braulio =?UTF-8?B?Sm9zw6k=?= Solano Rojas <braulio@solsoft.co.cr> Cc: freebsd-hackers@freebsd.org Subject: Re: mounting Mac OS .dmg files? Message-ID: <20081124002133.500eec9e@bhuda.mired.org> In-Reply-To: <44979.201.198.34.106.1227489354.squirrel@webmail7.pair.com> References: <4927E659.3010602@kukulies.org> <C93A045C-8070-453B-8533-43947CA9A823@gid.co.uk> <44979.201.198.34.106.1227489354.squirrel@webmail7.pair.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 23 Nov 2008 19:15:54 -0600 (CST)
Braulio Jos=C3=A9 Solano Rojas <braulio@solsoft.co.cr> wrote:
> I have an innocent question. I have read on the handbook and the thesis
> about the Linux ABI technical explanations that lead me to think that it
> could be possible to run Mac OS binaries on FreeBSD. I think that if the
> correct loader was implemented in execve and the Mac OS system calls were
> also implemented it would be possible to run Mac OS binaries. Am I right?
> (I am not asking anyone to support this feature, I just would like an
> hypothetic answer in order to improve my knowledge.) Of course, I suppose
> there would be technical challenges to solve as there are still for Linux.
> In fact, I would like to ask further: could this be possible for any
> operating system (without thinking about if it would worth it)?
In theory, you can provide an ABI for any OS that you care to emulate
the necessary calls for. In essence, that's what the WINE project is:
emulation of all the Windows API's required to run Windows
applications on a Unix/X11 platform.
The thing is, an OS these days is more than just a set of system calls
- it's a collection of shared libraries providing a complete user
interface. That's why you have to install large chunks of a Linux
system to run Linux binaries on FreeBSD - getting all the libraries
down to the system call level needed by those binaries (and in some
cases, you want GNU/Linux executable also, because the binaries expect
to invoke executables from Linux, not BSD, and they are different
enough to matter). Even then, the reason it works reasonably well for
GNU/Linux with X is because the X server/client API use IPC mechanisms
so you can get away with running a FreeBSD X11 server, letting the
Linux applications use Linux client-side libraries, and just make sure
the IPC calls are simulated properly (module hi-end graphics tools and
other late additions). Other OSs don't have as clean a division
between applications and the graphics subsystem, so you have to
provide all the services the OS provides for talking to the graphics
device as well. Linux gets another win here in that all the relevant
libraries are open source; for proprietary systems, even if you could
find a clean layer to switch platforms, you'd have to rewrite all
those libraries above that layer from scratch anyway. Which is why
WINE has to simulate all the Windows GUI calls using X11 code.
So while a Darwin (the OS underneath OSX) ABI would be possible -
though it's not clear how painful because it's not clear how visible
the MACH APIs are - it's not clear how useful it would be by
itself. You could run OSX applications that used X11 for the GUI after
building the appropriate libraries (just like Linux), but those apps
are probably available native anyway. You couldn't run applications
that use the various and sundry Mac-specific graphics (among other
things) frameworks, not without providing code to simulate all the
calls provided by those frameworks - which are proprietary, and not
part of Darwin. Which means this project now resembles WINE more than
the Linux ABI layer.
<mike
--=20
Mike Meyer <mwm@mired.org> http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081124002133.500eec9e>