Android gets tipsy on Wine, runs WINDOWS apps The man behind Wine, the not-an-emulator which runs Windows applications on Linux, has been showing off an early version for those desperate to run MS Office on their Android device. It was, according to Phoronix - who witnessed the demo - "horrendously slow", and running on a Mac which was itself running an Android emulator. …
Well that's what you get from proprietary system. You will end up having to support some old stuff nobody else runs any more, but switching to something else is far to expensive.
We already see that with companies basing their software on VBA and Excel. We will see that with companies using Java, Sharepoint or Cloud solutions for business critical work.
If you want to buy new systems now, try to look into the future. What will happen if the vendor doesn't exist any more? Can you go on hiring your own programmer to keep it updated? Can you replace modules of it one by one without affecting the whole system?
I have an old G5 running debianppc. I discovered that it is almost exactly twice as fast as an Athlon 1800+ when transcoding.
I suspect redeploying an old core2 is almost always a better option, especially when power consumption is taken into account. I keep mine because 7 fans keep it going through 40C+ hot days.
>"Wine is x86 only for obvious reasons."
Actually there's been some interesting experimentation with Wine on ARM too... people successfully installing and running Windows 98 on their ARM phones! Factor in work to draw on Qemu to get 32bit Windows XP code running and things start to look very interesting indeed... certainly makes this seem a tad myopic:
>"Windows applications running on an Android platform, which is technically impressive even if difficult to justify."
The host instruction set shouldn't matter. From what I can tell it's running on an Android emulator, and is working to translate Win API calls to Android API calls. This isn't new, there was a version of WINE running on Mac PowerPCs before they switched to x86 (DarWINE?)
>The host instruction set shouldn't matter.
Of course it matters.. the Windows executable is machine code for a certain instruction set..
>From what I can tell it's running on an Android emulator,
That doesn't really matter. Except for being slow as hell the Android emulator is just the same as a regular Android device running a debug build of Android. If you run an ARM AVD it's emulating a complete ARM system (which is why it's slow).
>and is working to translate Win API calls to Android API calls.
Windows executables aren't shell scripts. They might just call APIs which are reimplemented in Wine but this is all on the machine code level. To run x86 Windows executables you need to be able to run x86 code.. there is no way around that. If the host isn't x86 you have a lot more work fitting the host and the hosted Windows application together.. It isn't impossible but it's not simple at all.
>This isn't new, there was a version of WINE running on Mac PowerPCs
> before they switched to x86 (DarWINE?)
I'm sure someone tried to with a X86 emulator into Wine at some point but I think darwine only ever targetted x86 macs.
Oddly, there is that recent Motorola x86 thingy, the Razr i or somesuch..
Anyway, I regard this "because we can" rather than because it's immediately useful. If people only did things which were tiny incremental steps that actually made sense, very little of interest would ever get done.
(Plus, I always did have a weak spot for running emulators on emulators on emulators, as deep as I could make it go.. and yes, I know, WINE Is No Emulator or whatever)
Wine is not just for X86. Wine will also allow Non-Windows operating systems to run Windows ARM apps (i.e. Windows 8 ARM apps).
Wine can also be used as a porting aid - take a Windows app for which you have source, re-compile for ARM, link against libwine.so, and you have an app running on ARM.
"I doubt that..."
I agree, it would perhaps, have been interesting for the writer to spell out the grounds for his assertion.
What do you think?
Copyright? Patents? Not a chance, getting something to do the work of Windows, *without* using any of MS's code does not constitute infringement. See the Samba case for that.
Look and feel? Well if the OS is not actually running Windows just the application then again I can't see any way for MS to complain.
"though we'd expect Microsoft to make short work of that in a court of law if it felt inclined."
No, it's just a throw-away line and has no basis in reality.
I agree - as we saw elsewhere
http://the1709blog.blogspot.co.uk/2013/01/sas-v-wpl-programming-languages-not.html
A case about not being an emulator was found not to infringe copyright
World Programing Limited (WPL), creators of World Programming System, which replicated the functions of the SAS components. Crucially, World Programming System was compatible with the SAS language meaning that users were no longer tied to SAS and could use their own applications with World Programming System instead of the SAS system.
yeah, yeah - I'm sure there's a software patent in there somewhere however:
http://www.patentprogress.org/2013/01/31/why-newegg-is-exceptional-and-just-saved-you-money/
and then
http://techcrunch.com/2013/01/31/mark-cubans-awesome-justification-for-endowing-a-chair-for-eliminating-stupid-patents/
Indeed. If MS had a legal leg to stand on for stopping Wine it would have happened 10 years ago when they were so gung ho about stopping Linux that they launched their extremely inappropriately named 'Get the Facts' campaign (which, as I recall, contained very little in the way of actual facts and truckloads of dishonest FUD).
"This is likely down to the better architecture and implementation of the Linux kernel subsystems and drivers."
Most benchmarks show Wine being faster than XP but slower than Vista / Windows 7. I assume it's not that Wine is getting slower but that the graphics layer in later versions of Windows utilise the hardware better.
years ago I traced a keypress on a DOS2.2 machine all the way down to where it was stored in a ring buffer to become available for (the) application.
I gave up after about 45 minutes and lord knows how many subroutines and stack layers.
In CP/M it was about 3 layers deep and that was that.
That was the beginning of the realisation that Microsoft never rewrote code to make it more efficient. They just added another layer, and if they needed efficiency, they wrote a new back door.
Its not surpising that WINE can in theory do a better job. IF they know where all the backdoors are..
*years ago I traced a keypress on a DOS2.2 machine all the way down to where it was stored in a ring buffer to become available for (the) application.*
Dunno if you wanted just to track the keys but preprogramming 8259a is (was?) no so difficult.
WINE does amazing job on top the linux kernel, multiple wineservers (+desktops) it can handle more running application than a Windows on the same machine.
I just happened to have a mate who worked at a crusher, who was disposing of several hundred pallets of unsold / unsellable "Surfaces" and I had a way to crack the Microsoft Nazi / DRM bootloader-ware...
And I could install Xubuntu on the lot of them, give them a quick respray in pink and sell them for $20 each, in a stall, at some big tech industry convention, as "The Gay Lords - Up Right", - right next to the Microsoft stand.
Satan - Microsoft makes my Day.
Completely agree. I've sat there optimising the hell out of code to get it to run decently on the emulator when developing (doubles to floats, caching variables in lists, etc), only to find that it runs perfectly on my Nexus 1. The emulator runs like a dog, and I now try to avoid it as much as possible.
While the emulator is a dog, even the recent versions that run much better than older ones, It's not a good line that it "runs perfectly on my Nexus 1". Runs and runs efficiently are entirely different.
Often I think that developers should be purposefully given slow machines with low resources so they can produce efficient code rather than the monstrous bloated abominations that appear to be "normal" these days.
>While the emulator is a dog, even the recent versions that run much better than older ones,
That is certainly true. For me the GPU rendering made a huge difference. It's annoying to use with all of the weird artifacts in the emulator display but at least I can actually test against OS releases I don't have on a real device. It's a shame the 4.1 and 4.2 images are currently broken beyond use with all the Trace junk..
>It's not a good line that it "runs perfectly on my Nexus 1". Runs and runs efficiently are entirely different.
I use a few phones for profiling (when it's needed, most of the time it just works because I know what to avoid doing..). My "if it runs on this it'll run anywhere" device is a really crap ARMv6 with no 3D hardware phone running some hacked 2.1 ROM. There are things that perfect on that POS but struggle in the emulator with GPU rendering on a 2ghz+ machine.. simple things like updating a Canvas really fast so the user can draw something in realtime.
You've missed the point and you should only use the emulator to write code.
To give "users" the best experience ALL programs should be written on the slowest platform ( CPU, memory, network bandwidth etc). That way the programs will be written to be super efficient and when they are released to the public they fly.
The number of times I've been involved in faults where the newly rolled out SQL database runs like pants in remote locations with 1mb bandwidth (think multiple branch office to servers in a DC) and for the SQL guys to say "well it worked great in testing", testing being a client PC and server usually sitting on the same LAN switch...Then you (as a network engineer) spot the SELECT * FROM <whatever> in the code for every search and just sigh
I wrote a little maths program for the school I work for, which has gone down very well and been taken into their standard lessons now. It tests the kids, writes out their results to a network-accessible SQLite file (even simultaneous network access of 24 kids to the same database shared over SMB doesn't worry it - SQLite - what a library!).
Problem is, I wrote it the program in C for Windows using SDL libraries. Now, you *can* recompile it for ARM, throw it through the Android SDK / NDK and run it as a "Android" thing, as far as I'm aware, and get close to something that works on Android without needing to change the code (Simon Tatham's Portable Puzzle Collection, written in C, was made to run under Android in this way: http://chris.boyle.name/projects/android-puzzles) . But it's a bodge. A horrible, horrible, bodge. That, after hours of fiddling, I couldn't even get a test program to come out the other end that would work on a tablet. Sure, that's mostly just me and my setup, but it was really horrendous and involved lots of downloading, setting up, reconfiguring, recompiling, etc. just to get to that point.
But, Wine on Andriod, even if it's slow-as-molasses? That, I can use. Hell, I could just throw the same executable at the devices as I do at the network (probably just have to change the path of the network file to a local file) and have done with it. Fabulous. And I don't use enough of the internals of Windows to actually worry about WINE not supporting it or not being able to perform fast enough doing it.
So, where's the download?
If you don't want to use Wine, but still want to be multi-platform with native binaries, you can use Lazarus. It's a Delphi clone which can compile to at least Win32, Linux and MacOSX. I haven't tried the Android port yet, but yes it works on the Raspberry PI :)
It's aimed at GUI application and uses a fairly nice GUI framework which allows you do generate your GUIs via a designer and at runtime. And it can even scale your GUI to different font sizes without a single line of code. And you have native elements on every platform. (No idea how that looks on Android)
On a similar note, *Linux* on Android would be good too - as in, running anything that works on GNU/Linux.
Porting Windows to Linux often isn't that hard with languages like C or C++, and libraries like SDL, but like you say, I've hit problems trying to port to Android. My route has been to use Qt (the Android port is unofficial and in beta, but still seems a lot more supported and user friendly than SDL on Android), but it would be so much easier just to recompile a Linux version...
Yes, I'm talking about GNU/Linux - Android may be "Linux" in the sense of using the kernel, but that helps little when trying to port with the OS that-people-usually-refer-to-as "Linux" (maybe RMS was right that we should call it "GNU/Linux" after all...)
Is it possible to run GNU/Linux software on Android by installing libraries?
"Is it possible to run GNU/Linux software on Android by installing libraries?"
I have.
On a rooted device, you can set up a chroot environment with, say, Debian installed. Use a terminal emulator and, hey presto, you've got a Debian shell.
Add to that the Android X-Server app, and you've got linux GUI apps, too. Looks very odd (and hard to read without tweaking) seeing LXDE running on your mobile.
>Problem is, I wrote it the program in C for Windows using SDL libraries.
I guess this is SDL 1.2? The 1.2 port for Android was a hack AFAIK.. you should try 2.0. You will need to rework a lot of code but 2.0 works fairly well on Android and it fixes a lot of hairy bits in SDL.
>throw it through the Android SDK / NDK and run it as a "Android" thing, as far as I'm aware,
It's not as easy as that but it isn't too hard either.
> written in C, was made to run under Android in this way: http://chris.boyle.name/projects/android-puzzles) .
From the source it looks like some Java for UI level stuff and a bit of JNI calling into some existing C code. With SDL 2.0 your codebase can be totally C aside from a single Java class to startup/setup SDL and jump into your code. The Java + some bits of JNI'd C code isn't actually that bad of a solution though.. it's not "portable" though.
Most android devices run ARM processors. A mobile ARM processor emulating x86 instructions is never going to win prizes for speed. The most that can be hoped for is that the code behind the Win32 APIs is native, i.e. instruction emulation up to the call, a thunk layer and then native.
It might prove fast enough to run apps designed for an older generations of PCs though. Intel are messing around in the mobile space, so who knows, perhaps they could get it working well on their x86 friendly mobile processors.
Of course WINE apps can also be recompiled via winelib, so developers who take the effort to recompile their apps through gcc for ARM could run for all intents and purposes as native apps.
but if you want to run x86 binaries (targetting any API) on an ARM chip then *something* has to be an emulator.
Acorn produced one of these 25 years ago for the Achimedes - although back then x86 only meant 8086/87 for the emulator and speedwise it was lagging somewhat behind the 80286 ATs that were popular then.
The really clever part of this *could* be the GDI work - much of WINE is the translation of GDI graphics operations into X-Windows calls. Obviously to do this on Android means replacing all those X-Windows operations with the Android display driver primitives. Abstracting this out (with all the attendant hacking to make things match up) gives some hope that as display systems like Wayland start to deliver, WINE will be using native calls (as opposed to WINE calling the X-Windows translation layer on top of Wayland).
Of course, it may just be all done on top of FrameBuffer, or using HTML canvas. In which case it will always be slow.
Let's be honest: Wine is far from a perfect solution even in it's native environment of a POSIX based system. The challenges the Wine team faces are pretty significant. Frankly I'm impressed if it can get Windows apps to run on even x86 Android. If they get this to work on ARM Android then it's a amazing feat even if the apps do run dog slow.
Would be interesting to see ho fast it ran..
See the review link in my earlier post...
Yes you could.
But the world experts in this kind of technology: Transitive, who started at University of Manchester, are now part of IBM Power Systems division.
Maybe S2E's RevGen -> LLVM IR ->Thumb2 + Wine as shared object? + an indirection despatcher.
"bigger..."
Possibly not for code. ARM's Thumb2 instruction set was designed to improve code-density. That's never been a stated goal of x86 family which has become ever more baroque, constrained by its instruction encoding format (Prefix/overrides) Opcode Mod Reg R/M Sib Displacement Immediate.
If I am using MS Office this is likely a "work environment" with quite a few other Windows-only programs and little to no Unix software. So why would I want to run Android to run Wine to run my Windows-Programs? Add in that Windows is touch/stylus optimized and support for WACOM/NTrig is about as stable as Alphas "Storage Site 2" and the question get's even bigger (Assuming Android/x86 since Android/ARM makes even less sense)
I can understand WINE for the die-hard penguinista who wants to run a decend game but otherwise spends his time under Linux but those guys won't run MS-Office even if they could download it "free". And in the (rare) company that uses Linux desktops it is either OO/LO or they have a terminal server with MS-Office set up so the (typically developers) can use that in the rare occasion the need it
It is true that Wine, on Linux systems, is normally used on x86 Linux systems, to handle the OS calls. So additional software would be needed on the typical ARM-based Android device. But there's a well-known choice for that job in Linux as well - Qemu. So it's not as if instruction set emulation will have to be written from scratch.
I for my part have still one or two WinCE apps I bought a long time ago and would be happy to use under Android.
No need for CPU emulation then. I wonder how closely related the WinCE API was to the Win32 API...
As for running ancient x86 software - you can already do that. Just install the dosbox emulator and a Windows 3.x. Even win95 or one of its later incarnations would probably run fairly well. In that case you would need a Windows license, of course.
"I wonder how closely related the WinCE API was to the Win32 API..."
I think Microsoft's preferred terminology was "extended subset". In addition to API differences, however, there were differences in file system organisation and such like. You could write quite complex apps targetting both CE and desktop, but you'd need /slightly/ different code in various places. I'd be surprised if unmodified CE apps ran correctly on WINE.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
