Wine looks to bring Windows apps to Android
Wine could bring Windows apps to Google's Linux-based Android platform, but there are a few hurdles the project needs to jump first.
Wine - a recursive acronym from Wine Is Not an Emulator - was originally developed to allow selected Windows applications to be installed and run under Linux without support from the original developer. Since its inception, it has grown into a popular tool for running everything from Adobe Photoshop to new-release games - and while not everything runs without issue, its compatibility database is pretty impressive. For those who prefer commercial, rather than community, support, a paid-for Wine fork dubbed CrossOver is available for Linux and OS X.
Now, Wine is reportedly heading in a new direction with plans to release a version of the software that runs under Google's Linux-based Android mobile platform - potentially allowing smartphones and tablets to install Windows software and run it alongside native Android applications.
It wouldn't be the first time such a thing has been attempted: a port of DosBox emulates a 486-era PC and allows Android smartphones to run older MS-DOS applications, while a version of the QEMU machine emulator provides the option to emulate a somewhat more powerful system in order to install Linux or, with a fair bit of hacking, an older Windows version.
Both options suffer from serious performance problems, however - mostly because they run an entire operating system on top of Android. Wine, by contrast, is a compatibility layer that translates Windows API calls into their Linux equivalents - meaning applications can be executed without the need to have Windows running in the background. It's a system that has served Linux well, but the translation to Android is unlikely to be smooth.
For a start, there's the issue of instruction set architecture. Windows apps are developed and compiled for the x86 instruction set or its 64-bit equivalent, while the overwhelming majority of Android devices are based on ARM architecture processors - discounting a small number of devices running Intel's x86 Atom chips. The two aren't directly compatible, which is why DosBox and QEMU show often poor performance: they are having to emulate a full x86 processor on an ARM chip optimised for low power draw in a mobile device. The result is something quite some distance away from native performance.
Wine solves the issue of running a full version of Windows in the background just to access a single app, but it can do nothing for the issue of different instruction set architectures. Full details of how Wine for Android would operate are not yet available - the closest thing is a report from Phoronix that showed the software running on an x86 MacBook Pro in the Android SDK - but it would have a few options: emulate an x86 chip, like QEMU and DosBox, with all the performance penalties that implies; run only on x86 Android hardware, which is a tiny fraction of the market; or require developers to recompile their Windows applications for ARM before they would be compatible with the Wine shim.
Thus far, it's not clear what direction the project will take - but it's certainly likely to be a considerable time yet before you're firing the desktop version of Internet Explorer up on your Android smartphone.
Previous Article
21 Comments
Discuss in the forums ReplyRestricting it to x86 Android would work, but few commercial products use x86 hardware with Android. It might be handy for those few that do run such devices, but is it honestly worth the effort?
No, they're talking about replicating the API layer and not the hardware layer. So a 'standard' compiled app that is basically a list of calls to standard windows APi calls will work 'as is' and each call will be directed to a re-written equivalent.
But without any ability to run x86 code then their compatibility list is going to be limited.
But it's a start, and of course an extension of it will be to (potentially) run x86 windows apps on RT.
But lets not underestimate the amount of work it is to get even a subset of the required APIs re-written and stable. MS have not exactly been frugal when it comes to releasing new APIs.
Actually, it runs perfectly well on my Surface Tablet. So your point is?
This, but replace £1 with 5p
:?
That's sort of my point; for anything that's specific to the x86 ISA - whether that's the application binary or the APIs it calls - you're going to be SOL unless you can reverse-engineer that API and implement your own version of it, or wrap those calls to a Linux/Android ARM equivalent (if one exists).
Quite...
Meanwhile in the real world, compared to the number of Android tablets and iPads out there the Surface doesn't even warrant mentioning (see http://rcpmag.com/articles/2013/01/31/surface-rt-barely-registers.aspx). That isn't a criticism of the hardware or the software, it's a cold hard commercial reality.
With Microsoft pushing towards ARM themselves with Windows RT, developers may have to do this anyway. If they continue pushing ARM I wouldn't be surprised if Windows 9 (or a later version) allow the full version of Windows to run on ARM. The power of new ARM chips means they could easily power (low-mid range) laptops relatively soon.
It's been only three months of a poorly distributed product going against a really well-distributed one that has had nearly three years head start. Give it a chance to catch up.
Windows RT is the full version of Windows. It is just not unlocked. But that may still happen after all. When it's jailbroken you realise how it can do more or less everything Windows 8 can.
My post was in response to a claim that running MS Office on tablets is a moot point because it's available on WinRT. Whoopee-do, what about the overwhelming majority of tablet owners that don't have a Surface RT? My point was more that there would be an awful lot of people interested in running MS Office on Android or iOS tablets, as they are by far the most widespread tablets on the market.
It wasn't a criticism of the Surface or Win8/WinRT. In fact the Surface hardware looks pretty damn sweet; both the RT and Pro versions.
Good luck with that!
It does --as long as they are ported to ARM. I realise that there aren't many yet, but the list is growing.
(And as long as it has got Quake and Rainmeter in that list, who cares! :p)
I specifically said "Windows applications" in my post, not "cross-platform, open-source applications." When they are available for Windows RT, I'll accept that it can "do everything Windows 8 can do." But the fact that it can be made to run OpenTDD does not invalidate my point.
I don't know where you're getting this from.
I said the biggest benefit I could see to having Wine on Android is so that you can run MS Office on tablets (did I really need to clarify that I meant non-Microsoft tablets?).
Did I say that Microsoft should release Office on iOS or Android officially and criticise them for not doing so?
Did I say that Win8/WinRT/Surface/SurfacePro was rubbish or criticise it/them in any way?
If I'm moaning at all then I'm moaning about my posts being taken out of context or having words put in my mouth. Either respond to what I've actually said or stop trolling.
I think that we are talking cross purposes about what it can technically do and what it is allowed to do. Windows RT is a full port of Windows (including the bugs). I think that locking it was a mistake; it eliminates the main reason for choosing it over other OS's. An ARM CPU would struggle with many, but certainly not all legacy software and the individual software publishers can make the choice as to what they port to ARM and what would be pointless to. Perhaps Microsoft will change its mind. Outlook being trialled for RT certainly suggests that there is a camp that thinks that way.