FreeBSD cross-platform fork

Cogentleman

Cogentleman

Hey all, there was something that I've been pondering a lot lately.

Theoretically, let's say I had 1000 code monkeys at my disposal. What would be the feasibility of forking FreeBSD to make a kind of super OS that can run software from multiple OSes? From my understanding, the primary difficulty in doing so would be the difference in APIs that each OS has, but couldn't you design an OS with a base set of system calls, then have each Windows API call or POSIX API call map to an equivalent base system call or set of them? Then anything could run natively on this OS? Thoughts, please.
 
No need to fork, that kind of thing has been done already. The Linux "emulator", for instance. But it's taken the Wine guys a decade or so to get it to work some of the time for some things. ReactOS was/is going to be a system that can run Windows binaries, but it's in the same boat as Wine. Windows is not just an ever-changing API but an environment.

What is needed is not a lot of programmers, but a few who are serious experts on both the the host and guest operating systems. That, and a lot of money, and a lot of patience.

The competition is always going to be VM software running the actual other operating system with essentially 100% compatibility. And anyone can have that right now, and even expensive commercial operating systems would be cheaper to install than developing something.

But if you're an eccentric whiz kid who got out before some bubble collapsed with a net worth of nine or ten digits, it could be a fun project.
 
Not saying I'm about to go and do this or anything, and I'm also utterly of the opinion that redoing things that have been done for the sake of it is a waste of time. That being said, WINE is slow, as I'm sure we all know. Not to mention it only works for Windows. Not to disrespect the work those guys have done, of course, it's absolutely incredible in my opinion, I just see it as a different thing.

I'm talking about a personal hypothetical dream OS. An OS that can natively run Windows, OSX, Linux, even Android executables, and I can pick my favorite window manager and whatnot. Emulators get the job done, but with a huge investment would such a system be possible within a decade?

Like, let's say I'm Bruce Wayne, and have a huge sum of money. I hire a moderate sized team of experts dedicated to producing native compatability with each platform's executables, and obviously these would be experts working on it for several years. I guess I'm just wondering would such a task be so grand that there isn't a realistic amount of time or money or people that could be put on it to make such a thing a reality?
 
Sure, it's technically possible. For the right price, you could buy a Windows source license and the right to resell implementations of it. Is it practical? No. Bang for the buck, you could get a lot more by improving VM integration. There are some where a VM application window--just the window, not the whole desktop--can appear as a window on the host. To the user, it's just another window, although the UI might be a little different from the other windows. For Android, an ARM version of FreeBSD running on a fast emulator (pay the QEMU guy to do that) with that same type of window integration.
 
Cogentleman said:
I'm talking about a personal hypothetical dream OS. An OS that can natively run Windows, OSX, Linux, even Android executables, and I can pick my favorite window manager and whatnot. Emulators get the job done, but with a huge investment would such a system be possible within a decade?
Click to expand...
There are various practical reasons why this isn't going to work. Running Android applications natively will require an ARM CPU. The traditional i386/AMD64 architecture simply cannot run ARM code, so running Android applications natively will be out of the question.

Even if you only take into account x86 based operating systems there's still the issue of having the application use the correct ABI stubs. Although there's a lot of common ground (similar API/ABI functions) there's a lot that's rather "unique" to each OS. And because we're running binary applications we need to take into account how ABI functions are called. Some push arguments on the stack and issue a software interrupt, others have arguments stored in registers and call special functions. The operating system will need to figure out which one to use or the application will crash.
 
I suppose I should amend my previous statement, considering there isn't exactly such thing as a native Android app, considering it runs on top of the Dalvik VM. I was going to say that I would think it'd be possible if one were to make a variant that runs on x86 processors, but Google just announced one called ART that seems to verify my hypothesis (though of course correct me if I'm wrong).

But I suppose I'm wondering, although such practical reasons as disimilar ABIs are obvious obstacles, I guess I'm just wondering if they are such grand obstacles that they are virtually impossible to pull off? I'm under the impression that if a company such as Google or Apple put a huge amount of their resources to the task they could pull this off in a relatively small span of time, I'd think a couple years, it could be done, and the main reason is the fact that there is no company that actually has any good reason to do so. Which I agree, if I were in charge of any huge company out there this would not be a good use of my resources I don't think. Just wondering.
 
The more complex the system, the more difficult it is to make run with an ABI translation layer. Running Windows and Android applications means not just emulating the ABI, but providing a reasonably similar environment. Device drivers have to react the expected way, all the standard files and libraries must be present, and so on. Again, the FreeBSD Linux translation layer is a pretty good example.

Anyway, the point is that as the complexity of the environment increases, the amount of work to successfully get it working increases, probably geometrically. A large company would have the resources to do it, maybe relatively quickly compared to open-source projects like Wine. But a company would have to justify it financially. And there is also the concern of legal battles.
 
The problem is that implementing the API as documented doesn't get you halfway there.

Application writers have dependencies on undocumented but currently-real behavior that they found on Reddit or by trial and error. If you can't run those your compatibility layer is useless in practice because it doesn't run the software the user wants and you can't change the software, and since you don't have the source code you can't directly find out what they expect the OS to do for a given hack at hand. Sure, you can see the API call they are making, and with a bit of effort what the native OS returns for this call, but good luck predicting the full spectrum of parameter or states.

Then there is the whole DirectX/Direct3D mess which will cost you lots of performance.
 
You must log in or register to reply here.
Back
Top