Feeds

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.

Page:

Facepalm

This is not about phones

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

7
0
Bronze badge
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
0
Bronze badge

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
0
Anonymous Coward

I can't wait

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

2
8
Silver badge

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

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

4
0
Silver badge
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?)

0
1
Bronze badge
Unhappy

Re: "The annoying application"

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

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

2
0

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.

3
0
Silver badge

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

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

1
0
Bronze badge

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

0
0
Bronze badge

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.

1
0
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)

1
0
Silver badge

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.

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

17
0
Bronze badge
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.

14
0
Bronze badge
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
0
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
0
Silver badge
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).

9
0
Bronze badge
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.

5
1
Anonymous Coward

Re: its not using any there code

What is 'there code'?

People upvoted this?

2
3
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
0
Anonymous Coward

Re: My guess would be Balkan

Hu gen dong sounds more Viet / Cambodian to me

1
0
Anonymous Coward

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

10
3
Bronze badge

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.

7
1
Happy

@AC 12:53 GMT

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

7
3
Silver badge

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

0
3
Silver badge

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

2
0

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.

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

0
0

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

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

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

11
0

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.

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

0
0

Sweet! Old PC games on my Android!

Or, maybe, just use DosBox

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

5
0
Silver badge

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

0
0
Silver badge

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

0
0
Silver badge

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

0
0
Bronze 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?

4
0
Silver badge

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)

0
0
Silver badge

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

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

0
0

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.

0
0
Silver badge

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?

0
0

Page:

This topic is closed for new posts.