[Wine] Is it possible to port (part of) WINE to iOS?

[ryan woodsmall]

> *sigh* He'll never figure it out on his own...
> 
> @SpawnHappyJake: Ryan was being sarcastic.

Sorry Chip, you figured me out.  I normally try to avoid feeding the trolls or reciprocating.  Sometimes though...  I could just say "kernal" again but I'll try to address this like an adult.

Jake: for real, what you're saying is not impossible.  Nobody worth their salt would simply say "impossible!" to that because most folks around here A.) know what kernels, operating systems & instruction sets are and B.) know intrinsically that a Turing-complete machine (i.e., any modern computer's instruction set) can simulate any other Turing-complete machine, albeit with some caveats.

However, what you're proposing has been beaten to death by people wanting to run everything from Windows mobile PIM apps on their Android phones to World of Warcraft on their iPads.  Yes it can be done.  But no, it would likely not be worthwhile due to speed/time/development constraints.  Furthermore it's well outside the scope of the Wine project to implement a full machine emulator and enough tooling necessary to simulate a complete skeleton operating system to then run slowly-emulated applications.  Wine is a reimplementation of the Windows API with an inbuilt compatibility layer that relies on the underlying operating system.  It is not a full system emulator, and should not be.

If you want to see how hard these problems are take look at ReactOS.  Or qemu.  Or the myriad other projects that aim to achieve these ends.  There are a number of problems you'd encounter such as:

- slow machine emulation; i.e., instruction set differences (even with a JIT CPU simulator)
- endian translation issues
- missing/incomplete display technology (Wine is basically tied to X11; Android uses Skia and iOS Quartz)
- underlying OS and API/SDK features missing or disabled due to security constraints and embeddedness
- hardware resource constraints such as limited memory, minimal GPU features, etc.

Unless you want to undertake all that work, and the integration pieces necessary to make it all fit together nicely, this is basically a dead end for any near-term development.  Darwine was a decent stab at this but it's dead for a reason.  Cost/benefit is something you need to consider in any open source project.  The benefit, in terms of usefulness and performance, is basically not there while the cost, in terms of time, is exorbitant. -r