Box86 - Linux Userspace x86 Emulator


Am i correct in that Linux's userspace is gnu? Would this be a gnu emulator then? Or is more like a general unix-like userspace that is linux compatible?
(not to devolve the threat into a naming debate, just curios)
 
Am i correct in that Linux's userspace is gnu? Would this be a gnu emulator then? Or is more like a general unix-like userspace that is linux compatible?
(not to devolve the threat into a naming debate, just curios)
UserSpace, as oposite to KernelSpace. Are you taking about BSD or things like that? If that's the case, no idea if it would work. I would say it would, but some minor adaptation may be needed (no idea, I only test on Linux)
 
UserSpace, as oposite to KernelSpace. Are you taking about BSD or things like that? If that's the case, no idea if it would work. I would say it would, but some minor adaptation may be needed (no idea, I only test on Linux)
No not talking about BSD or anything, just wondered if this had any relation to the gnu as it's usually listed as the userspace/userland on many Linux distros wiki pages.
 
No not talking about BSD or anything, just wondered if this had any relation to the gnu as it's usually listed as the userspace/userland on many Linux distros wiki pages.
Hmmm, I will say no, no relation. It is just to say it emulate stuffs that happens in the Linux Userspace, nothing more.
 
Last edited:
UserSpace, as oposite to KernelSpace. Are you taking about BSD or things like that? If that's the case, no idea if it would work. I would say it would, but some minor adaptation may be needed (no idea, I only test on Linux)
As I understand it, it'd be unlikely to work as is on any given BSD. The BSD kernel dates back quite a lot further than the Linux kernel, so does some things quite differently, and different BSDs have quite different kernels now that dragonflyBSD has appeared. I don't know how this affects the userspace apis to be honest, but this suggests it's not a simple matter of plug and play, and there some kind of shim between linux processes and the BSD kernel and libs called the linux compatiblity layer.
 
Did you do any performance tests comparing native and emulated games?

What is your expectation and your goal regarding the performance?
 
Did you do any performance tests comparing native and emulated games?

What is your expectation and your goal regarding the performance?
I am focussing on compatibility for now. Not much on performances. Without JIT, I'm not expecting too much, but it's not that bad, really. But I do plan to integrate a JIT later.
 
Did you do any performance tests comparing native and emulated games?
What are you suggesting would be a fair test for a native game? It'd be more useful in my mind to run some sort of cpu tester, and seeing where it comes out hopefully somewhere between 486sx and Pentium 90MHz or somewhere like that.
 
Wine is not in the scope of Box86. (I had another project in mind for Wine, but it's similar to Hangover, so not sure I'll do it one day).
May I ask why? Is there some reason WINE is different from running other Linux programs in Box86?
 
May I ask why? Is there some reason WINE is different from running other Linux programs in Box86?
Box86 use native call as much as possible, to avoid emulating useless call. So system library like libc, libm and other, are "wrapped", and the ARM version is used, even if the program is i686 architecture.
Wine may use many non-wrapped function, rarely used, that would need some work to wrap. Also, running Emulated Wine is not in the Box86 phylosophie.
So, while it may work, I haven't tried. And I will not tried my self.
Again, it may work (but chances are that some or many function will be "missing"). You can try it and report if you are interrested.
 
Wouldn't it make sense to wrap all of the wine calls to run arm wine to reimplement any win32 apis and so on? Granted, that's going to be a lot of work, given how wine wraps almost everything any anything in the windows apis, but it seems to be the more effeicient direction to head in.
 
Wouldn't it make sense to wrap all of the wine calls to run arm wine to reimplement any win32 apis and so on? Granted, that's going to be a lot of work, given how wine wraps almost everything any anything in the windows apis, but it seems to be the more effeicient direction to head in.
Yes exactly. That was my plan for WinBox. But I haven't really started that project. And it doesn't make sense to start it now before Box86 is an more "feature complete" state...
 
Box86 use native call as much as possible, to avoid emulating useless call. So system library like libc, libm and other, are "wrapped", and the ARM version is used, even if the program is i686 architecture.
Wine may use many non-wrapped function, rarely used, that would need some work to wrap. Also, running Emulated Wine is not in the Box86 phylosophie.
So, while it may work, I haven't tried. And I will not tried my self.
Again, it may work (but chances are that some or many function will be "missing"). You can try it and report if you are interrested.
I will give that a try when I get my Pyra, thank you!
[doublepost=1552251926,1552251887][/doublepost]
Yes exactly. That was my plan for WinBox. But I haven't really started that project. And it doesn't make sense to start it now before Box86 is an more "feature complete" state...
If you ever start it, let us know! It sounds like a neat idea.
 
Are the Combatible X86 Libraries inside the Codeblocks?

How to use it for a Noob like me?

Is there an .sh which download the mostly important "Wrapper Files"?

I read and read about Box86 but do not understand it completly how to use it.

Which Commands should i Type in for using it?

I want to try with it this Evening :)
 
Are the Combatible X86 Libraries inside the Codeblocks?

How to use it for a Noob like me?

Is there an .sh which download the mostly important "Wrapper Files"?

I read and read about Box86 but do not understand it completly how to use it.

Which Commands should i Type in for using it?

I want to try with it this Evening :)
It's inside latest Codeblocks beta yes (but the version of box86 is already a bit outdated). Both i386 version of libstdc++ and libgcc_s are already setup and will be found by box86 automatically.
Just type "box86" to have some help. Look in the README in the github page also.
 
Back
Top