Closed DarkShadow44 closed 4 months ago
In short I would expect more performance from box32 if it's focused on 32-bit. At the same time it's nice to use the same thing for 32-bit and upcoming 64-bit.
Is there any official news regarding box32? I don't really see why they would duplicate their efforts, maybe this box64 32bit support is their alternative to box32?
Is there any official news regarding box32? I don't really see why they would duplicate their efforts, maybe this box64 32bit support is their alternative to box32?
Box32, like Box64, is constituted in 3 major part: the x86 emulator (that is also in box64 and hangover), the elf reader (same as box86 one) and the libarian. The Librarian is the hard part, because it need to handle the change of bitness betwwen 32bits (the program) and 64bits (the OS it runs on), like Wow64 on wine does exactly.
It's not yet decided if box32 will be a stand alone program or part of box64... Wait and see.
So if the emulator stays unchanged from box64 there's nothing of value for hangover as it already uses that one
So if the emulator stays unchanged from box64 there's nothing of value for hangover as it already uses that one
Yeah, the emulator part of box32 and box64 will be identical. Less maintenance for me, and the emulator is already pretty solid, and multi-platorm, no need to specialised it.
Thanks for the discussion, I removed Box32 from README.md
The readme says
depends on the early 32-bit emulation of Box64
. But I thought the whole point of box32 would be the emulation of 32bit code on 64bit ARM. So if box64 can do that already, what would be the difference with box32?