Wine On Android Is Coming For Running Windows Apps | Hacker News Reader

Wine On Android Is Coming For Running Windows Apps

phoronix.com

93 pointsmicrowise41 comments

If Android gains traction on x86-based tablets and other mobile devices, CodeWeavers has a lot of commercial opportunities for pushing the running of Windows software on Android.

I honestly don't see how there would be that much of a market. Any native Android implementation of a particular program will be much nicer to use than a Wine emulated program. Really the only use I have ever found for Wine and other emulation programs is for running Windows games on other platforms and usually the performance is too poor or unreliable except in the case of very old games.

SkiFree would actually be pretty fun on an Android.

Here you go: https://play.google.com/store/apps/details?id=com.kudzu.plan...

DOSbox has been out for Android for quite some time. Takes a little configuring, but it works. I've seen people running windows 3.1 and win 95 on Android as well.

http://androiddosbox.appspot.com/

http://forum.xda-developers.com/showthread.php?t=1325643

>running Windows games on other platforms and usually the performance is too poor or unreliable except in the case of very old games

IME this is out-of-date.. I run PES 2013 with wine. (I haven't tried many other games, but quite a few are compatible). I have to run it on one setting lower, other than that its almost identical to running it on windows, wine is impressive these days. I agree it would be quite limited with ARM, although there are x86 phones.

This is very much a YMMV thing. Some things work an order of magnitude better than others under wine.

I've also had things which have worked fine under wine get an update, or I've updated something else on my system and then all of a sudden it completely breaks.

>Wine and other emulation programs

Wine isn't an emulator (it's in the name!), it's a compatibility layer.

>usually the performance is too poor or unreliable

Nonsense. Wine being a compatibility layer means that, while some apps are quite a bit slower, performance is generally good.

In prinicple, anything worth having is worth having in a Android-native touch-optimized implementation. But...

There is a lot of software, especially on a formerly hegemonic platform like Windows with a decades-long history, that will never get ported or functionally recreated.

Most of it deservedly so, but some some of it is going to be valuable enough to enough people that a compatibility system will be just the right thing because a reimplementation would take too long and/or cost too much.

usually the performance is too poor or unreliable except in the case of very old games.

This is far from universally true - in my experience it is actually slightly backwards. A few years ago I had to benchmark a Windows program against a Linux one I had written, and the Windows program ran slightly faster under WINE than under Windows. (This was mostly computational, without much use of Windows APIs, and no graphics in the timed sections.)

The reason WINE works is that it essentially runs x86 programs as-is and provides the needed linkage (shared libraries) used by the Windows programs. (Windows syscalls are usually issued through an intermediary shared library, so WINE can trap them there.) Much of this work is re-implementing the various libraries; bugs in WINE can usually be attributed to missing functionality (incomplete or stubbed functions) or bugs in the WINE implementation.

Running an x86 program directly on ARM is … impossible. So maybe WINE on ARM can serve to run WinRT applications… but none of the existing x86 Windows applications can run without x86 emulation, which would be absurdly slow on Android devices.

Edit: Another commenter says that the project wiki suggests using qemu to run the x86 code on ARM, and then trap calls into native (ARM) WINE libraries. This approach seems unlikely to yield good performance. I am concerned that different C and C++ calling conventions means some additional work will have to be done to cleanup function arguments at every call, which is just more overhead on top of x86 emulation…

>>>So maybe WINE on ARM can serve to run WinRT applications

That would be a trick: How do you buy RT apps when not on a Microsoft-approved device?

Good question. I am not actually familiar with the specifics of WinRT; I haven't touched Windows regularly since the early 2000s.

Maybe you first buy them on a MS-approved device and either copy the app from that device or are able to get a DL link that works on the other device.

But that would make you buy what you want to avoid -- an MS-approved device.

Not everyone who wants to run RT apps on non-MS devices is trying to avoid MS in every aspect of their lives.

But Wine on x86 Android would be useful.

Sure, but then it's just normal WINE. Not WINE on ARM, which is suggested by the article =).

Actually, the performance might not be as bad as you would at first think. A good chunk of the work done by a graphical application is actually done by the graphics system supplied by the "OS", and in this case, that code would be natively compiled.

It's analogous (performance-wise) to writing gui apps in python - provided you're not trying to do any heavy lifting in the actual application code, it could work quite well.

Apple's Rosetta technology for running PowerPC code on Intel Macs actually worked this way, and the performance for most apps was really quite acceptable. That said, Rosetta had the advantage of moving from relatively slow CPUs to the fastest in the world. In the case of ARM / Android, you would be trying to run Windows apps on a slower CPU, so the results wouldn't be as good as Rosetta...

I agree with everything you have said. I would just add that I think many of the most useful (and widely used) Windows applications do do heavy lifting in native code — Word, Excel, and Photoshop are all good examples here. They aren't explicitly number-crunching like BTC mining or SETI@Home, but there is a lot of x86 code running under the hood.

What we need is an x86 emulator that JIT compiles the x86 code to ARM.

Which is exactly what qemu does. Although there is significant space for optimizing the host code produced by qemu.

Cross-architecture compilation is ridiculously hard, and the balance between JITing the code and the resulting code's speed is very, very fine, and often depends per process: you don't know when translating an executable page how much it might be run. It could never execute or it could execute trillions of times. You can't just translate every bit of executable code because you WILL spend more time translating than executing. On the other hand, you need to translate well enough that you have good cache performance, make good use of registers (some are usually reserved for emulation state), and the extremely nasty bit of translating specialized math instructions and SIMD instructions, which often have implementation-specific nastiness that causes issues if you translate naïvely. Add onto that fundamental differences that always arise (e.g. unaligned/aligned loads, memory protection/translation differences/access modes, debug/performance registers, appropriate clock timing when necessary, hardware access.... it's endless) and you find yourself relying on pretty horrific hacks to avoid bad performance.

In short, unless you have specialized hardware for this (Transmeta!) it's going to be a massive undertaking.... so if you're confused by the host code produced by qemu, it's a lot harder to produce than you might think, although the primary reason is that producing better code often is not worth it because of the translation time. There may have been recent work to move some of the research in PL JIT over to translation, e.g. progressively translating better code the more it's run, but I haven't looked in a while.

In my view what qemu produces is perfectly acceptable. On the other hand applying optimization approach of Java's HotSpot or Python's PsyCo to qemu might be interesting. (and something like that was already done by HP's Dynamo which could "emulate" parisc code on parisc faster than direct execution)

Still architecture differences are significant, but in this case for what you really want to accomplish ARM is reasonably similar to i386.

>Another commenter says that the project wiki suggests using qemu to run the x86 code on ARM, and then trap calls into native (ARM) WINE libraries. This approach seems unlikely to yield good performance. I am concerned that different C and C++ calling conventions means some additional work will have to be done to cleanup function arguments at every call, which is just more overhead on top of x86 emulation…

There is already similar project about running x86 windows application on top of Windows RT:

http://forum.xda-developers.com/showthread.php?t=2095934

It will be interesting to compare.

So we have windows apps on android, and android apps running on windows 8?

I love ambitious projects like this, but I can't help but think this is a waste of some formidable developer talent. First, running Windows apps on Android will give Android even more of a battery life problem than it already has. Second, this will possibly increase the chance that some software shops will be even lazier in making native ports of popular applications and just tell people to use WINE. Third, if people want this kind of experience they should just buy a Surface Pro or some kind of Ubuntu touch device that can already run WINE. Again, I applaud anyone who will undertake a project of this difficulty but I just don't see the point.

You don't have to run Android on battery.

I don't see the issue. It's not like people are going to be tossing up Wine apps in the market en massé.

Do you need ARM applications, or does it emulate X86 too?

I don't know, but from the Wine ARM wiki:

"""Possible goals: run the assembler parts of x86 in qemu and call function in Wine compiled for ARM"""

Wine is not an emulator. ;)

This is misleading, since it means it's not a CPU emulator, however it's an emulator of Windows in a sense that it mimics the Windows environment and system libraries.

I always just assumed it was a tongue-in-cheek joke à la GNU.

http://www.winulator.com/

P.S. knowing this dude's previous work (coLinux), he's pretty good :)

Anyone know what the benefits/drawbacks are of running WINE on a MacBook/Linix versus running Windows in a VM such as VirtualBox?

With a VM you will be able to run more software more reliably but suffer a significant performance hit and require a Windows license for the VM and it will take a chunk of your RAM.

WINE is more likely to be glitchy & unreliable with many programs, will require special configuration in some cases and may not work at al in others. However since it doesn't have to emulate a computer (it basically re-implements parts of the Windows API) the performance is usually on a par or only slightly worse than native windows. You don't need a Windows license to run WINE however.

How difficult would it be to get Wine running on a jailbroken iOS device?

It would be a waste of time; the devices are arm and not x86.

Windows runs on ARM too. Not sure any of the apps are worth emulating though.

all this just to run internet explorer on a macbook

http://www.modern.ie/virtualization-tools

Reply on news.ycombinator.com