I know that programs that are built on one OS won't work on another, like a Windows program on a Linux distribution, and that there are programs that translate those system calls into system calls that the current OS can read (Wine for Linux). However would it theoretically be possible for there to be an OS that can understand the original system calls for programs built for the three main OSes (Windows, Linux, and Mac OS X)?
closed as unclear what you're asking by user40980, gnat, Doc Brown, GrandmasterB, Dan Pichelman Nov 17 '14 at 13:24
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Windows NT was specifically designed to support multiple OS "personalities". In fact, it originally wasn't even intended to be a drop-in replacement for Windows and DOS, it was intended as a drop-in replacement for OS/2!
On Windows NT, applications aren't written against the NT kernel, instead they are written against an OS personality, which in turn sits on top of the NT kernel. The original Windows NT shipped with 4 personalities: Win32/WinNT, DOS/Win16, OS/2, and Unix. This meant that you could not only run Windows NT applications, you could also run DOS applications, OS/2 applications, and even Unix applications unmodified. Nowadays, the OS/2 personality is removed, and the Unix personality is shipped separately.
Many Unix systems have similar facilities. In the beginning, when Linux was "the new kid on the block", Linux needed to be able to run applications for other Unices if it wanted to be viable. During that time, support for adding foreign Unix applications was added to Linux, for example Intel developed iBCS, which allowed Linux systems to run all sorts of Unix applications (Solaris, 386BSD, FreeBSD, NetBSD, BSDI/386, SVR4 (Interactive, Unixware, USL, Dell etc.), SVR3 generic, SCO, SCO OpenServer 5, Wyse V/386, Xenix V/386, Xenix 286). There's even the
binfmt_misc module, which allows Linux to run applications written against arbitrary ABIs, by handing them off to a userspace program which interprets them.
Nowadays, it is the other way around: Linux is the established player, and the other Unices implement ABI compatibility with Linux. HP/UX, IBM AIX, FreeBSD, and many others all can run Linux applications unmodified.
It would be pretty easy for Apple to develop an OSX personality for Windows NT. It would also be possible for Microsoft to develop a version of Windows NT that runs as a personality on top of Mach alongside OSX. Whether those companies would do that is a totally different matter, though.
The thing is, MACs and PCs are fundamentally different hardware, in terms of CPU architecture. Compilers, for that matter, are nothing more than translation tools that rewrite your code from an abstract high-level programming language to low-level "words" (actual groups of bits) that the processor is reading and executing inside its logical hardware architecture. Under these circumstances, what you're suggesting would be like having someone who doesn't even know Latin is (was) a language, do complex mathematical operations using Latin numerals.
There are some approaches to the issue of cross-compatibility - for example, the Java Virtual Machine (JVM) is a piece of software that in itself depends on the architecture and OS of the machine on which it resides, but offers at the other end an "interface" to the CPU, hardware and system components, that is the same across all architectures, empowering Java applications to behave the same in various environments.
The issue with this, however, is that the translation layer offered by the JVM must use additional resources and do extra processing besides just the instructions in your application, in order to translate the instructions into the language that the native CPU understands - thus degrading the overall performance.