I know there are many differences between OSX and Linux, but what makes them so totally different, that makes them fundamentally incompatible?
Linux – What makes OSX programs not runnable on Linux
compatibilityexecutablelinuxosx
Related Solutions
Another way is by calling the interpreter and passing the path to the script to it:
/bin/sh /path/to/script
The dot and source are equivalent. (EDIT: no, they're not: as KeithB points out in a comment on another answer, "." only works in bash related shells, where "source" works in both bash and csh related shells.) It executes the script in-place (as if you copied and pasted the script right there). This means that any functions and non-local variables in the script remain. It also means if the script does a cd into a directory, you'll still be there when its done.
The other ways of running a script will run it in its own subshell. Variables in the script are not still alive when it's done. If the script changed directories, then it doesn't affect the calling environment.
/path/to/script and /bin/sh script are slightly different. Typically, a script has a "shebang" at the beginning that looks like this:
#! /bin/bash
This is the path to the script interpreter. If it specifies a different interpreter than you do when you execute it, then it may behave differently (or may not work at all).
For example, Perl scripts and Ruby scripts begin with (respectively):
#! /bin/perl
and
#! /bin/ruby
If you execute one of those scripts by running /bin/sh script, then they will not work at all.
Ubuntu actually doesn't use the bash shell, but a very similar one called dash. Scripts that require bash may work slightly wrong when called by doing /bin/sh script because you've just called a bash script using the dash interpreter.
Another small difference between calling the script directly and passing the script path to the interpreter is that the script must be marked executable to run it directly, but not to run it by passing the path to the interpreter.
Another minor variation: you can prefix any of these ways to execute a script with eval, so, you can have
eval sh script
eval script
eval . script
and so on. It doesn't actually change anything, but I thought I'd include it for thoroughness.
Since wine is a re-implementation of the Windows API - you're looking for a re-implementation of the Macintosh API or various "kits" that Apple provides to let OSX apps link to the system frameworks. I don't know of any that fit the bill. The only thing even close is the Chamelion Project which brings the UIKit from iOS to Mac OS X.
Since I don't have a real library for you, Lion is allowed to be virtualized on Mac hardware. Perhaps that would work for your needs while you wait for a lighter implementation like wine?
There are about a hundred hits on Google about "how to run lion in vmware" and all basically point to the check for a server plist file presence check that the installer wants to see before it will proceed. Here is one that's fairly clear on the steps.
Best Answer
The whole ABI is different, not just the binary format (Mach-O versus ELF) as sepp2k mentioned.
For example, while both Linux and Darwin/XNU (the kernel of OS X) use
scon PowerPC andint 0x80/sysenter/syscallon x86 for syscall entry, there's not much more in common from there on.Darwin directs negative syscall numbers at the Mach microkernel and positive syscall numbers at the BSD monolithic kernel — see xnu/osfmk/mach/syscall_sw.h and xnu/bsd/kern/syscalls.master. Linux's syscall numbers vary by architecture — see linux/arch/powerpc/include/asm/unistd.h, linux/arch/x86/include/asm/unistd_32.h, and linux/arch/x86/include/asm/unistd_64.h — but are all nonnegative. So obviously syscall numbers, syscall arguments, and even which syscalls exist are different.
The standard C runtime libraries are different too; Darwin mostly inherits FreeBSD's libc, while Linux typically uses glibc (but there are alternatives, like eglibc and dietlibc and uclibc and Bionic).
Not to mention that the whole graphics stack is different; ignoring the whole Cocoa Objective-C libraries, GUI programs on OS X talk to WindowServer over Mach ports, while on Linux, GUI programs usually talk to the X server over UNIX domain sockets using the X11 protocol. Of course there are exceptions; you can run X on Darwin, and you can bypass X on Linux, but OS X applications definitely do not talk X.
Like Wine, if somebody put the work into
then running an OS X program "natively" on Linux could be possible. Years ago, Kyle Moffet did some work on the first item, creating a prototype binfmt_mach-o for Linux, but it was never completed, and I know of no other similar projects.
(In theory this is quite possible, and similar efforts have been done many times; in addition to Wine, Linux itself has support for running binaries from other UNIXes like HP-UX and Tru64, and the Glendix project aims to bring Plan 9 compatiblity to Linux.)
Somebody has put in the effort to implement a Mach-O binary loader and API translator for Linux!
shinh/maloader - GitHub takes the Wine-like approach of loading the binary and trapping/translating all the library calls in userspace. It completely ignores syscalls and all graphical-related libraries, but is enough to get many console programs working.
Darling builds upon maloader, adding libraries and other supporting runtime bits.