back to article 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. …

COMMENTS

This topic is closed for new posts.
  1. Kay Burley ate my hamster
    Facepalm

    This is not about phones

    Unless the phone is running an Intel chip. Wine is x86 only for obvious reasons.

    1. Captain Scarlet
      Facepalm

      Re: This is not about phones

      Good point, now to wait for someone to say why dont we use "The annoying application" we pay a fortune for and hasnt been updated properly since WIndows 3.1 with Wine to make it more mobile :(

      1. Christian Berger

        "The annoying application"

        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?

        1. Captain Scarlet
          Unhappy

          Re: "The annoying application"

          Or buying out the company where "The annoying application" was used.

    2. Phil W

      Re: This is not about phones

      THIS!

      There is that orange branded phone which is based on an x86 atom so I suppose that might work but otherwise meh at this.

      If wine could some how work on non-x86 platforms I would be using it on my old power mac g5 that's running Linux mintppc.

      1. Pookietoo

        Re: If wine could some how work on non-x86 platforms

        It can ... if you run an X86 emulator, and speed isn't an issue ...

      2. P. Lee

        Re: This is not about phones

        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.

    3. Anonymous Coward
      Anonymous Coward

      I can't wait

      The opportunity to do something I've never wanted to do, on a slow buggy emulator.

      1. Pookietoo

        Re: I can't wait

        X86 Linux Wine means I don't have to boot Windows or run a virtual machine for any of the Windows apps that I regularly use. This version may be an early proof-of-concept demo, but it's potentially a very powerful tool for non-X86 tablet/mobile platforms.

    4. Androgynous Crackwhore
      Gimp

      Re: This is not about phones

      >"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."

    5. Annihilator
      IT Angle

      Re: This is not about phones

      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?)

      1. Anonymous Coward
        Anonymous Coward

        Re: This is not about phones

        >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.

        1. Anonymous Coward
          Anonymous Coward

          Re: This is not about phones

          "I'm sure someone tried to with a X86 emulator into Wine at some point but I think darwine only ever targetted x86 macs."

          Darwine was aimed at PPC, but shelved after the transition to x86 (hence the name - Darwin was the underlying Mac OS on PowerPC)

    6. Anonymous Coward
      Anonymous Coward

      Re: This is not about phones

      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)

    7. itzman

      Re: This is not about phones

      Not so.

      I have run, very slowly and incredibly badly, x86 DOS apps on a G3 power PC mac.

      You simply need to build a x86 machine code interpreter..

    8. Anonymous Coward
      Anonymous Coward

      Wine not just X86

      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.

  2. Anonymous Coward
    Anonymous Coward

    Do be quiet!

    "though we'd expect Microsoft to make short work of that in a court of law if it felt inclined."

    I doubt that, it's been around for a very long time now, many commercial products have been sold off the back of the work done on WINE. So can the FUD, eh?

    1. nematoad
      FAIL

      Re: Do be quiet!

      "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.

    2. gerryg
      Thumb Up

      Re: Do be quiet!

      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/

    3. Androgynous Crackwhore
      FAIL

      Re: Do be quiet!

      Indeed. Also, isn't "...it maps function calls from <previous vendor's> apps into its own execution code. As such you won't need a <previous vendor's> licence to run <new solution>..." the very foundation of Microsoft's entire business? Sauce for the goose...

    4. sisk
      Linux

      Re: Do be quiet!

      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).

  3. Longrod_von_Hugendong
    Linux

    How would M$ makes short work of this...

    in court? its not using any there code, its not modifying the .exe's in anyway, i cannot see how this would be a problem.

    1. Anonymous Coward
      Anonymous Coward

      Re: its not using any there code

      What is 'there code'?

      People upvoted this?

      1. Anonymous Coward
        Anonymous Coward

        Re: its not using any there code

        Awww... come on AC. He also began with a minuscule, wrote "I" with a minuscule, used "its" in place of "it's" - twice... but didn't you spot his name? "Longrod_von_Hugendong" Poor chap's obviously foreign. My guess would be Balkan.

        1. Anonymous Coward
          Anonymous Coward

          Re: My guess would be Balkan

          Hu gen dong sounds more Viet / Cambodian to me

  4. Anonymous Coward
    Anonymous Coward

    If I wanted my apps to run slowly and inefficiently, I would invest in a Surface.

    1. Anonymous Coward
      Anonymous Coward

      When they work (and a fair few do), a lot of Windows apps run faster under Linux and Wine than they do under Windows, on the same hardware. This is likely down to the better architecture and implementation of the Linux kernel subsystems and drivers.

      1. DrXym

        "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.

        1. itzman

          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..

          1. stanimir

            keystroke handling

            *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.

    2. Chris007
      Happy

      @AC 12:53 GMT

      Eadon - I see you've gone anon for these types of comments now

      1. Dave 126 Silver badge

        Re: @AC 12:53 GMT

        >Eadon - I see you've gone anon for these types of comments now

        Yeah, I don't think I've seen him post as 'Eadon' since that Ubuntu on Samsung story.

    3. Anonymous Coward
      Devil

      I would invest in a Surface if...

      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.

  5. Anonymous Coward
    Anonymous Coward

    >and running on a Mac which was itself running an Android emulator.

    The Android emulator is insanely slow (even with GPU rendering and the x86 image + hardware support) so I wouldn't be surprised if it isn't a lot better on a real phone or tablet.

  6. My Alter Ego
    Thumb Up

    Re: Daniel Palmer

    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.

    1. Nick Ryan Silver badge

      Re: Daniel Palmer

      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.

      1. Anonymous Coward
        Anonymous Coward

        Re: Daniel Palmer

        >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.

      2. John H Woods Silver badge

        Re: Daniel Palmer

        As a performance engineer, I completely agree. And they should be forced to execute their unit tests (on client-sized PCs) against production-size DBs.

    2. Chris007
      FAIL

      Re: Daniel Palmer @My Alter Ego

      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

  7. Idocrase

    Sweet! Old PC games on my Android!

    Or, maybe, just use DosBox

    1. Anonymous Coward
      Anonymous Coward

      Do you even know what WINE is?

      It is an implementation of the Win32 API which tries to act as a translation layer between Windows API calls and the API of another OS.

      It is not a virtual machine, CPU emulation or any of the usual emulator stuff.

      1. itzman

        It would have to be a CPU emulator as well on non 86 devices.

        1. Anonymous Coward
          Anonymous Coward

          > It would have to be a CPU emulator as well on non 86 devices.

          ...and almost certainly wouldn't be. It's not what WINE is trying to do.

          However, if you had a Windows app compiled for ARM, you might be able to run it on "Wine for Arm".

        2. Richard Plinston

          > It would have to be a CPU emulator as well on non 86 devices.

          If CPU emulation is required then the x86 parts run under QEMU and the WINE parts run native.

  8. Lee Dowling Silver badge

    Strangely relevant

    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?

    1. Christian Berger

      slightly off-topic

      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)

    2. Mark .

      Re: Strangely relevant

      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...

      1. Androgynous Crackwhore
        Boffin

        @ Mark

        Wouldn't "Linux on Android" be, erm, Linux?

        I mean, you seem to be talking about a full GNU/Linux environment... so... install a set of (free) GNU libraries onto your nice Android kernel (Linux) and.. hey presto.. you'll have... erm... GNU/Linux

        1. Mark .

          Re: @ Mark

          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?

          1. Dr. Mouse

            Re: @ Mark

            "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.

    3. Anonymous Coward
      Anonymous Coward

      Re: Strangely relevant

      >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.

    4. ForthIsNotDead
      Facepalm

      Re: Strangely relevant

      Why on _earth_ would you want to do that, when you have a perfectly good Win machine to run your code on?

      Utterly perplexed...

  9. LinkOfHyrule
    Joke

    running on a Mac which was itself running an Android emulator

    What would happen if you ran inside the Windows a virtualised Mac OS - does the world slowly and painfuly end or something?

    1. Anonymous Coward
      Anonymous Coward

      Re: running on a Mac which was itself running an Android emulator

      No, the three OSs begin to distort and recompile themselves, each stealing code from one another to create one super OS known as BloatOS.

      It has the metro interface, the driver support of x64 linux and the pricetag of a Mac.

      1. sisk

        Re: running on a Mac which was itself running an Android emulator

        It has the metro interface, the driver support of x64 linux and the pricetag of a Mac.

        And right there you have the makings of the perfect horror movie to scare the crap out of nerds.

      2. Simon Harris
        Coat

        Re: running on a Mac which was itself running an Android emulator

        It has the metro interface, the driver support of x64 linux and the pricetag of a Mac

        ... and the reliability of a Sinclair QL.

        1. Nick Ryan Silver badge

          Re: running on a Mac which was itself running an Android emulator

          ... and the reliability of a Sinclair QL.

          No idea about that, I've been waiting since last week for it to boot.

    2. Silverburn
      Happy

      Re: running on a Mac which was itself running an Android emulator

      Here's a better one...

      Bootcamp into win7, then VM into OS X using the original OS X install as the VM image.

      I think this is the IT equivalent of disappearing up your own arse.

    3. Graham Dawson Silver badge

      Re: running on a Mac which was itself running an Android emulator

      Ah, you can't fool me, it's VMs all the way down!

  10. DrXym

    It's never going to be fast

    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.

    1. Anonymous Coward
      Anonymous Coward

      Re: It's never going to be fast

      A mobile ARM processor emulating x86 instructions

      WINE is not an emulator.

      1. Ken Hagan Gold badge

        Re: It's never going to be fast

        WINE may or may not be an emulator, but if you want to run x86 binaries (targetting any API) on an ARM chip then *something* has to be an emulator.

        1. Simon Harris

          Re: It's never going to be fast

          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.

          Original Acorn PC emulator 1988 review

          Revised Acorn PC emulator 1991 brochure

      2. DrXym

        Re: It's never going to be fast

        On non-x86 architectures something has to emulate the instructions. Either the binary is run through QEMU which somehow passes off to Wine, or Wine itself gains the capability to emulate. Either way, something has to emulate or there is no Wine at all.

        1. Dr. Mouse
          Pint

          Re: It's never going to be fast

          "or there is no Wine at all"

          NOOOOOOOO!

          Ah, wait, you didn't mention beer. Is my beer safe? Do we need emulation for beer to exist?

      3. Rukario
        Joke

        Re: It's never going to be fast

        "WINE IS NOT an Emulator" is not an emulator.

  11. Anonymous Coward
    Anonymous Coward

    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.

  12. sisk

    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.

  13. itzman

    I wonder...

    ..if anyone has written a microcode program to make an ARM execute x86 machine code.

    Would be interesting to see ho fast it ran..

    1. Simon Harris

      Re: I wonder...

      Would be interesting to see ho fast it ran..

      See the review link in my earlier post...

  14. bed
    Happy

    Re: It's never going to be fast... Part II

    Yes, there is an x86 emulator for ARM and I remember using it, running Wordperfect 5.1 for DOS on an Archimedes, after first using Kermit to transfer all the files from a PC.

    1. Robert Carnegie Silver badge

      Could you "compile" an x86 binary to run on ARM?

      That is, produce ARM code that is functionally ejuivalent to x86 code?

      I suppose it'd be bigger...

      1. ganymede io device

        Re: Could you "compile" an x86 binary to run on ARM?

        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.

  15. mmeier

    The question is - WHY?

    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

    1. Lars Silver badge
      Linux

      Re: The question is - WHY?

      Google is using Wine for Picasa on Linux, runs fine, and everything needed is in the download.

  16. Keith Oborn

    I remember-

    A colleague running a Spectrum game in a DOS emulator run in a DOS box under WINE on a SCO machine.

    "It was impressive not because it was done well, but because it was done at all"

  17. MrT

    Announcement from the WINE team...

    ... "This development sponsored by Kingston and Crucial"

    Full-blown Windows apps on Android? We're going to need a bigger microSD card... ;-)

  18. John Savard

    Qemu

    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.

  19. Chairo
    Thumb Up

    WinCE anyone?

    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.

    1. Ken Hagan Gold badge

      Re: WinCE anyone?

      "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.

This topic is closed for new posts.

Other stories you might like