Linked by Thom Holwerda on Thu 28th May 2009 12:08 UTC, submitted by lemur2
Linux There are several ways to run Windows programs on Linux (virtualisation, WINE) and vice versa really isn't a problem either with Cygwin, or better yet, native ports thanks to the Windows variants of Gtk+ and Qt. Still, what if Windows support was built straight into the Linux kernel? Is something like that even possible? Sure it is, and the Chinese figured it'd be an interesting challenge, and called it the Linux Unified Kernel.
Thread beginning with comment 365782
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: FrankensteinOS
by MacMan on Thu 28th May 2009 13:57 UTC in reply to "RE: FrankensteinOS"
Member since:

[q]What's next? Add OSX?

Why not? Remember OSX IS UNIX!, OSX is 100% source compatible with Linux, Solaris, BSD, ..., (well for non-GUI calls), such as pthreads, fork, mmap, etc.. and all the other UNIX goodies that are not available natively on Windows. (side note, why are the Windows low level APIs so freaking ugly compared to their UNIX counterparts???)

As for GUI stuff, OSX is kind of, essentially source compatible, via GNUStep.

Now, for binary compatibility, there is a slight issue, in that Linux natively supports the ELF and a.out executable formats, and OSX is Mach-O, and they are slightly different, although, the actual executable code, i.e. the instructions are identical (they are both X86), just how they are loaded into memory, and external linking is resolved is different.

However, although I am not an expert, I suspect that it probably would not be that big of a deal to add Mach-O linking support to Linux, much like BSD supports a Linux binary compatible runtime. Considering that Linux supports ELF and a.out, I suspect that it should be possible to add some code to the linker to also support Mach-O.

Reply Parent Score: 1

RE[3]: FrankensteinOS
by WereCatf on Thu 28th May 2009 14:08 in reply to "RE[2]: FrankensteinOS"
WereCatf Member since:

Support for OSX binaries is easy otherwise but AFAIK there is no OSX-compatible userland available whereas for Windows-compatibility one can just use Wine. So, being able to run OSX-binaries under Linux would require a lot, LOT more work.

Besides, there is little incentive for that. There's a whole lot more software for Windows than there is for OSX, and most of OSX software is already available for Windows as well. The same applies to drivers also; there are far fewer drivers for OSX whereas the ones that exist are also available for Windows.

Reply Parent Score: 2

RE[3]: FrankensteinOS
by ba1l on Thu 28th May 2009 14:20 in reply to "RE[2]: FrankensteinOS"
ba1l Member since:

Yeah, you probably could implement a method for running OS X applications on Linux. There are three basic approaches I can think of.

First, the WINE approach. You implement a user-space application that can load and run Mach-O binaries, and service OS X system calls. Then, you need a reimplementation of the OS X userland libraries.

Second, paravirtualization. Take the existing OS X kernel, make it work under KVM with appropriate paravirtualization hooks, and use that to run OS X binaries. Then, you need a reimplementation of the OS X userland libraries.

Finally, the approach that Solaris and FreeBSD use to run Linux applications, and the approach LUK takes to run Windows applications. Natively implement the system calls in the kernel, providing the ability to run Mach-O binaries directly. Then, you need a reimplementation of the OS X userland libraries.

In any case, you still need the OS X userland libraries. Those libraries aren't nearly as numerous as the Windows ones, and at least the low-level libraries are open-source, but there are still a lot of them. Gnustep provides some of them, but certainly not all of them.

Probably a more realistic goal than WINE or ReactOS though.

Reply Parent Score: 1

RE[3]: FrankensteinOS
by boldingd on Thu 28th May 2009 16:59 in reply to "RE[2]: FrankensteinOS"
boldingd Member since:

(side note, why are the Windows low level APIs so freaking ugly compared to their UNIX counterparts???)

Because Win32 is a C++ API. ;)

That's a really good question: I worked with C++/Win32 for one homework assignment in college... and swore, "never again." That really is a fugly API. Amusingly, most of the hard-core Windows advocates in the class had the same opinion. They where used to Java, and had never actually directly used the Win32 API either; they where surprised at how hideous it actually turned out to be.

Edited 2009-05-28 17:01 UTC

Reply Parent Score: 1

RE[4]: FrankensteinOS
by JonathanBThompson on Thu 28th May 2009 19:33 in reply to "RE[3]: FrankensteinOS"
JonathanBThompson Member since:

Things that are COM/ActiveX appear to be C++ based, though they're really quite agnostic to the host language: they just have a specific binary layout that's most closely associated with C++, but can be done in other languages if you desire.

Win32 for the low-level stuff itself outside of 3D graphics and some other COM-based stuff, is C based: perhaps you're thinking of the added on ActiveX libraries, DirectX, and more recently, some of the GUI controls, unless you're confusing MFC with Win32: MFC is a bad C++ wrapper around the Win32 API that tends to add as much trouble as it claims to solve.

Reply Parent Score: 2