Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Windows Software Coming To Android Via Wine

Soulskill posted about a year and a half ago | from the run-an-android-emulater dept.

Android 107

SternisheFan sends this quote from ZDNet: "Software that allows Windows apps to run on Android devices was demoed at the Fosdem 2013 open source conference this weekend. The demo by Alexandre Julliard, one of the original developers of Wine, showed Wine running on an emulated Android environment. Phoronix reports the performance of Wine on Android to be 'horrendously slow' but says these problems were attributed to it running on an emulated environment rather than a native Android OS. ... The makers claim it bypasses many performance and memory penalties of other methods for simulating computing environments, such as running virtual machines, by translating Windows API calls into POSIX calls on the fly. The Android OS predominantly runs on ARM-based devices today, and a separate demo at the Fosdem conference showed Wine running on ARM-based hardware. There was no news on when support for ARM-based devices or Android will be added to a publicly available Wine release."

cancel ×

107 comments

Sorry! There are no comments related to the filter you selected.

TL;DR (4, Funny)

YodasEvilTwin (2014446) | about a year and a half ago | (#42790589)

Some guy speculates that horrendously slow Wine on Android might allow you to use all 3 WinRT apps that don't have Android versions.

Re:TL;DR (0)

Anonymous Coward | about a year and a half ago | (#42790753)

Or let an android based desktop OS be able to still use old windows applications. If it is an x86 system, It could have better compatibility with old apps (windows 98 era) then windows 8.

I will lol if this is the case.

Re:TL;DR (3, Interesting)

TheGoodNamesWereGone (1844118) | about a year and a half ago | (#42791107)

Emulating W9x under qemu is tolerably fast but running even something like TinyXP not so much-- the latter boots in about 5 minutes. The main problem though, is screen resolution. At minimum you need a screen capable of 800x600 (1024x768 really), and that doesn't count the real estate needed for the onscreen keyboard most users will be employing. I have no doubt the wine devs can make this work, but people without sooper-dooper high-res displays on their Android gadgets will be disappointed.

Re:TL;DR (4, Interesting)

viperidaenz (2515578) | about a year and a half ago | (#42791517)

Like that now 6 month old 10 inch 1980x1200 acer tablet? Or that new Asus with 1980x1200, or the old Asus with 1280x800, or the rumored new Samsung tablet coming out with 2560x1600? or that 5.3" galaxy note with 1280x800, the new Galaxy S4 with 1920x1080?

Re:TL;DR (2)

smegfault (2001252) | about a year and a half ago | (#42793531)

All with pixel densities so high you're going to need a stylus and an on-screen magnifier just to double-click "My Computer".

Re:TL;DR (0)

Anonymous Coward | about a year and a half ago | (#42793735)

DPI settings. Use them.

Re:TL;DR (1)

viperidaenz (2515578) | about a year and a half ago | (#42794601)

Yes, if its your cup of tea to use a 440dpi screen with 72dpi fonts.

Re:TL;DR (1)

gbjbaanb (229885) | about a year and a half ago | (#42795853)

or a HDMI cable, 46" "monitor" and an external pointing device connected via USB.

It works for me, probably scares the sh*t out of Ballmer - which is why they updated their programming APIs to something completely incompatible with win32.

Re:TL;DR (1)

deergomoo (2689177) | about a year and a half ago | (#42795777)

The Nexus 10 has a 2560x1600 screen.

Re:TL;DR (1)

c (8461) | about a year and a half ago | (#42796531)

I have no doubt the wine devs can make this work, but people without sooper-dooper high-res displays on their Android gadgets will be disappointed.

And those with sooper-dooper high-res displays get the fun experience of using applications designed exclusively for mouse and keyboard use on a touch display. Even if the Wine folks do a bang-up job of translating touch to mouse, there's going to be a lot of cases where it won't work (games, in particuar) and it's going to limit the set of usable applications even further.

And if that high-res display happens to be a phone, well, best of luck using an application designed for 21" at 96DPI on a 4.5" 300DPI display.

Ah, more viruses (1)

andy_spoo (2653245) | about a year and a half ago | (#42790755)

Wine, bringing windows viruses to Android. Cheers guys.

Re:Ah, more viruses (4, Insightful)

silviuc (676999) | about a year and a half ago | (#42791347)

1) You clearly have no idea how Wine works
2) Please provide a list of incidents where Wine helped to proliferate Windows viruses on Linux or Unix machines

Re:Ah, more viruses (2, Interesting)

Anonymous Coward | about a year and a half ago | (#42792329)

Re:Ah, more viruses (0)

Anonymous Coward | about a year and a half ago | (#42792857)

Yes, a virus can do half of what it does on Windows in Linux through Wine if you help configure it and get it working, boy I'm impressed. A malicious bash script could do more damage. The way Linux (Unix actually) is designed from the ground up is secure; a "virus" could only run if it was explicitly run by something, e.g. the user, an automated script. The only way a virus is going to hit Linux through Wine is if it was specifically written to do so, in which case, well you're fucked anyway.

Too lazy to log in so posting as AC.

Re:Ah, more viruses (1)

tehcyder (746570) | about a year and a half ago | (#42797985)

The way Linux (Unix actually) is designed from the ground up is secure; a "virus" could only run if it was explicitly run by something, e.g. the user, an automated script

Yes, it's lucky there are no careless/stupid uses of Linux who will just click "yes" to "do you want to install the free NakedGirls screensaver" and supply the root password when asked, isn't it?

It's been said many times before, but the main reason Windows is so insecure is because so many people with no understanding of computers use it.

Re:Ah, more viruses (1)

Waldeinburg (737568) | about a year and a half ago | (#42797291)

In an older test (http://archive09.linux.com/articles/42031) the most succesful virus managed to go into an endless loop, actually having negative performance influence on Linux – until Ctrl-C was hit.

Performance (0)

Anonymous Coward | about a year and a half ago | (#42790821)

All Android apps run "horrendously slow" in the Android emulator on the desktop. I think the article implied that Windows apps running via WINE on an actual Android device may have perfectly fine performance, like Windows apps running via WINE on a Linux desktop. Remember, "WINE Is Not an Emulator", it is more like a set of bindings between the win32 and Posix APIs.

Re:Performance (2)

um... Lucas (13147) | about a year and a half ago | (#42791541)

But aren't the early windows versions extremely tied to x86? So running them via wine on an android will involve emulating a pentium or 486 on the arm chip? That sounds like a recipe for horrendously slow to me...

Re:Performance (0)

Anonymous Coward | about a year and a half ago | (#42792037)

Intel are actually making x86-based Atom chips for mobile phones nowadays, even if they are only in a couple of phones. Use it with an x86 chip and there's no emulation required.

Re:Performance (0)

Anonymous Coward | about a year and a half ago | (#42792067)

There's no emulation. WINE translates the WIN32 calls to POSIX calls, and as long as those calls are supported by Wine and ARM OS it will run fine. However, some of the tied applications like games don't work well because they make specific calls into libraries (ie DirectX) which don't easily translate or are very difficult to reverse engineer into equivalents.

Re:Performance (2)

DrXym (126579) | about a year and a half ago | (#42791689)

An ARM processor emulating x86 is not going to be fast in any circumstances. The best you could hope for is that everything on the other side of the Win32 API is native so only the client code is emulated. It might suffice for older Windows apps or games.

Re:Performance (1)

Jorl17 (1716772) | about a year and a half ago | (#42792471)

Everything on the other side of the WIn32 API is native indeed, with Wine. I'm not sure if you were asking that or somehow implying it, though I figured I'd clear it up.

Re:Performance (0)

Anonymous Coward | about a year and a half ago | (#42797409)

Bluestacks, YouWave, WindowsAndroid and I'm sure others let you run Android natively in Windows. You could also setup a VM or dual boot with Android x86.

Re:TL;DR (0)

Anonymous Coward | about a year and a half ago | (#42790865)

Yeah`1

Re:TL;DR (5, Informative)

Curate (783077) | about a year and a half ago | (#42791117)

The article is about WINE. WINE doesn't allow you to run WinRT apps. It allows you to run Win32 apps (which is quite a large catalog... but then your joke wouldn't work so well). However WINE still isn't compatible with every Win32 app. WINE is stuck at around the Windows 2000 era in terms of the APIs it offers, and even then it has numerous bugs and is relatively slow compared to Win32 on actual Windows. Still, although it sounds like I'm bashing WINE, I'm not; I'm just pointing out its limitations. WINE is still extremely useful for allowing quite a lot of software to run.

Re:TL;DR (4, Informative)

powerlinekid (442532) | about a year and a half ago | (#42791707)

The last time I ran WoW on Wine (around 2009) I had a higher FPS than Windows XP on the same machine.

Re:TL;DR (1)

Anonymous Coward | about a year and a half ago | (#42793291)

That's because graphic features like anti-aliasing, ambient occlusion, anisotropic filtering, and more are often not available or ignored when running under WINE. Couple that with the fact WoW, a hugely popular game among basement-dwelling faggots, has had the shit tweaked out of it.

Re:TL;DR (0)

Anonymous Coward | about a year and a half ago | (#42794987)

I resent that! Don't equate us basement dwellers with faggots.

Faggots are like maggots, with an f.

Re:TL;DR (1)

Smauler (915644) | about a year and a half ago | (#42793573)

WoW is almost 10 years old. It's an MMO that some people play on the PC. However, it's far, far from cutting edge or decent graphics on the PC.

Re:TL;DR (0)

Anonymous Coward | about a year and a half ago | (#42792213)

It may be "useful for allowing quite a lot of software to run", but last I tried it about 18 months ago under Linux, it would not
allow me to run a .NET-based application and judging from the comments in the various fora, it was way off the radar screen
(since my app had nothing to do with gaming).

Since then, I went with an Apple iMac and installed Parallels and Windows Home Premium. Yes, much more expensive, but
I don't have to fool around with every code drop trying to wonder what combination of distribution and patches will allow me
to run an application that needs to talk to a serial line and an external sound card.

I had been running various distros (primarily [Open]SuSE, but occasional dabbling with Fedora, Ubuntu, and others) for over a
decade when I finally decided I'd had enough of trying to suture a working system together and worrying that the latest patches
for one component wouldn't break other components. Yes, it's a walled garden, but it works... solidly...

Re:TL;DR (0)

Anonymous Coward | about a year and a half ago | (#42792413)

For no-nonsense Windows application support on Linux I use VirtualBox OSE (free software) and Windows 7 (free student license). Always actually running a virtualized version of Windows, but the host operating system is still Linux.

On the other hand, if you do want to use OS X but miss WINE, then check out the Darwine [wikipedia.org] project which lets you use WINE on OS X.

In short, mentioning OS X vs. Linux in this thread is just trolling; virtualization and WINE both work fine on both OSes and have the same pros and cons irrelevant of the host OS.

Re:TL;DR (1)

aztracker1 (702135) | about a year and a half ago | (#42792713)

Heh... I have run Linux as my main desktop with VMWare Workstation for Windows virtual machines... I've had a number of issues with running Linux on the desktop.. a full virtual version of windows wasn't one of them.

Re:TL;DR (1)

HJED (1304957) | about a year and a half ago | (#42794155)

Most older .NET apps work, but you have to use the WINE tricks patch to install the .NET runtime first. I find for very common apps like Office and Photoshop WINE works very well.

Re:TL;DR (1)

tehcyder (746570) | about a year and a half ago | (#42798133)

judging from the comments in the various fora

Further proof that slashdot needs a "-1 wanker" moderation option.

Re:TL;DR (1)

robsku (1381635) | about a year and a half ago | (#42792393)

Not bashing? "stuck at around the Windows 2000 era" - hmmm, I know it's behind windows, always will be (as long as windows will come with new versions), but it's not by any way that much behind.

Re:TL;DR (1)

snadrus (930168) | about a year and a half ago | (#42792495)

Starcraft 2 (around 2010) works well, and its upcoming expansions will most-likely continue to.

Re:TL;DR (1)

Jorl17 (1716772) | about a year and a half ago | (#42792497)

You were modded informative, IMO, for part of your post. Wine is not stuck in the Windows 2000 era for sure, as I have run many applications specifically designed for XP (and some made for Vista and Seven). You are right when you say that it "is relatively slow compared to Win32 on actual Windows", but you should add that this actually isn't for the majority of cases, or at least not in my experience. Anything DirectX related is bound to be slower in Wine, yes, but I've had better performance in Wine on multiple occasions.

And yes, you are again right when you say it has numerous bugs ;]

Re:TL;DR (1)

1u3hr (530656) | about a year and a half ago | (#42793083)

Wine is not stuck in the Windows 2000 era for sure, as I have run many applications specifically designed for XP

My desktop PC runs Win2k. There are very few Win32 apps it can't run. However, in the last year new releases are becoming incompatible. I can't update Flash from version 11, for instance. So, if it's "stuck in the Windows 2000 era" that actually means you can run just about any XP or Vista program up to 2012.

Re:TL;DR (1)

Smauler (915644) | about a year and a half ago | (#42793613)

My desktop PC runs Vista... but I _still_ have a win2k installation that boots when I want it, off an old drive.

It's a good OS... as long as you don't want to run any modern applications, or games.

Win2k is EOL and unpatched (1)

tepples (727027) | about a year and a half ago | (#42797863)

However, in the last year new releases are becoming incompatible.

Perhaps it's just developers not taking the time to test their products on an operating system with known vulnerabilities that Microsoft will never patch.

Re:Win2k is EOL and unpatched (1)

1u3hr (530656) | about a year and a half ago | (#42798861)

Perhaps it's just developers not taking the time to test their products on an operating system with known vulnerabilities that Microsoft will never patch.

Actually, its Microsoft's new compilers that make it impossible to generate Win2k compatible versions. They don't have a choice.

I hear people going on about "vulnerabilities" in the OS. You're a fool if you trust the OS, new or otherwise. I use third party security, the OS is never exposed. In any case, it's worked for over 10 years and I've never had a security problem. But compatibility will force me to upgrade in a year or so I think. Then I'll have the problem of making all my old software work in the new OS. I don't want to spend the time on that till I have to.

Re:Win2k is EOL and unpatched (1)

tepples (727027) | about a year and a half ago | (#42801265)

Actually, its Microsoft's new compilers that make it impossible to generate Win2k compatible versions. They don't have a choice.

And MinGW has stopped working?

I use third party security, the OS is never exposed.

What sort of "third-party security" are you talking about? And what happens when an exploit is found that owns your machine even before the packet gets to the "third-party security" product?

Re:TL;DR (1)

HJED (1304957) | about a year and a half ago | (#42794153)

If you want MS Office on your phone though this would be great (for obviouse reason MS Office is extreamly stable on Wine)

Re:TL;DR (1)

donaldm (919619) | about a year and a half ago | (#42794521)

If you want MS Office on your phone though this would be great (for obviouse reason MS Office is extreamly stable on Wine)

I thinks this begs the question Why?

Having what normally is a application that is more suitable to reasonably sized screen, think say 10" and above (ok I would concede 7") as well as a keyboard and mouse (or touch-pad). IMHO It would be really only bragging rights to run any Office suite (not just Microsoft Office) on a mobile phone since you would not be very productive. Of course there would be many who would point out to me that they can be very much more productive to which I would reply. "Have you or firm paid for your Microsoft License or have you joined the Green Parrot Brigade" and "Get a life".

BTW You can get LibreOffice for Android for free (no adds), it can open and write Microsoft Word documents so why bother with emulation software to install Microsoft Office when you can get a whole suite of Office software (not just LibreOffice) for Android for little if any cost..

Re:TL;DR (1)

petman (619526) | about a year and a half ago | (#42795007)

No, MS Office is not extremely stable on Wine. For example, check out the AppDB for MS Word here:
http://appdb.winehq.org/appview.php?appId=10 [winehq.org]

Re:TL;DR (1)

DarkOx (621550) | about a year and a half ago | (#42795829)

WINE is stuck at around the Windows 2000 era

Totally false. Sure not everything is implemented and some stuff is stubbed but outside a few little used system level APIs thinks SQL need. If it works on XP it probably runs on WINE.

Re:TL;DR (1)

helix2301 (1105613) | about a year and a half ago | (#42795889)

Wine is a step in the right direction maybe eventually we will be able to run virtual phone os. Maybe virtualbox or vmware will make a product for the phone.

Yo Dawg (1)

DJ Jones (997846) | about a year and a half ago | (#42790623)

Yo Dawg, I heard you like Windows, so I decided to put Windows inside yo' Android being emulated on yo' Windows.

Re:Yo Dawg (4, Interesting)

0123456 (636235) | about a year and a half ago | (#42790845)

Back before there were native Sinclair Spectrum emulators for unix, I used to run a DOS Spectrum emulator in a PC emulator on a Sparc. Worked OK, there were enough extra CPU cycles to handle all the translation from Z80 to 8086 to Sparc and still play the games at full speed.

Re:Yo Dawg (0)

Anonymous Coward | about a year and a half ago | (#42792125)

Some of us 'lived' on PCDitto on the Atari ST.. Which ironically ran faster than the same speed PCXT... even tho the hardware clock wasn't that much faster ( oh, we could also emulate a Mac at real speed too )

Re:Yo Dawg (1)

Saffaya (702234) | about a year and a half ago | (#42793897)

PCDitto as a pure software PCXT emulator ran slowly. Which is quite understandable.
However, as with other PCXT emulators back then, there were little hardware boxes linked to the PC itself that contained an Intel CPU.
Those were faster.
http://en.wikipedia.org/wiki/Atari_ST#Utilities [wikipedia.org]

As for emulating Mac, it was the work of Dave Small and his amazing Spectre GCR, that required a set of Mac ROMs.
Once set, your ATARI ST would become a Mac, running 20% faster, with a screen estate 20% larger while using the same exact CPU at the same speed.
A testament to his programming skills, to the sane design of the ATARI ST by Shiraz Shivji (done in 5 month http://en.wikipedia.org/wiki/Shiraz_Shivji [wikipedia.org] ) and the boneheadedness of Apple at the time (an OS programmed in PASCAL .. yuck).

But can it run Crysis? (2, Funny)

Anonymous Coward | about a year and a half ago | (#42790635)

Crysis, all settings on full, on my Galaxy Note 2?

Re:But can it run Crysis? (1)

SirAdelaide (1432553) | about a year and a half ago | (#42791127)

I reckon I'll use it to run Notepad, so I can take notes on my phone, and Solitaire, so I can play games when I'm out.

I doubt anything more heavy duty would run fast enough, and besides, I can usually remote desktop to my home PC from my phone if I need to.

Re:But can it run Crysis? (1)

deergomoo (2689177) | about a year and a half ago | (#42795787)

I reckon I'll use it to run Notepad, so I can take notes on my phone, and Solitaire, so I can play games when I'm out.

I can't tell if you're joking.

Re:But can it run Crysis? (4, Informative)

Nerdfest (867930) | about a year and a half ago | (#42791481)

Yeah, you joke, but on my tiny little Sansa MP3 player running Linux/RockBox will run Doom, which used to take what was considered a pretty hefty PC to run. Just wait a bit.

Re:But can it run Crysis? (0)

Anonymous Coward | about a year and a half ago | (#42793663)

That's an arm device running a native port, yes impressive, but in no way comparable to emulating x86 on arm.

Re:But can it run Crysis? (1)

Smauler (915644) | about a year and a half ago | (#42793681)

Doom required a pretty hefty PC 20 years ago or so.

Re:But can it run Crysis? (0)

Anonymous Coward | about a year and a half ago | (#42794977)

Yeah, you joke, but on my tiny little Sansa MP3 player running Linux/RockBox will run Doom, which used to take what was considered a pretty hefty PC to run. Just wait a bit.

In case it wasn't clear due to the "Linux/RockBox" naming. Rockbox is not linux, it has its own kernel!

Re:But can it run Crysis? (1)

neilsnat (1236924) | about a year and a half ago | (#42796153)

Nitpick: Rockbox is NOT linux :)

Re:But can it run Crysis? (1)

Nerdfest (867930) | about a year and a half ago | (#42796971)

Thanks, I thought it was.

Any practical use? (1, Interesting)

tramp (68773) | about a year and a half ago | (#42790673)

Of course it is nice to see it is possible to run wine on Android but does it have usefull IRL applications?

Re:Any practical use? (1)

Anonymous Coward | about a year and a half ago | (#42790695)

Microsoft Office and Photoshop 7. *ducks*

Re:Any practical use? (1)

mspohr (589790) | about a year and a half ago | (#42790929)

What is this "Ducks" application?

Re:Any practical use? (1)

oodaloop (1229816) | about a year and a half ago | (#42791197)

This one? [wikipedia.org]

Re:Any practical use? (0)

Anonymous Coward | about a year and a half ago | (#42790811)

I suppose if your phone has HDMI out and you own Bluetooth keyboard then you have a system for old PC games.

Re:Any practical use? (0)

Anonymous Coward | about a year and a half ago | (#42790933)

assuming those games were written to run on the ARM architecture. Now if they could make x86 style apps run on an android system that is ARM, now that would be intersting!

Re:Any practical use? (2)

PRMan (959735) | about a year and a half ago | (#42791085)

I suppose if your phone has HDMI out and you own Bluetooth keyboard then you have a system for old PC games.

We already have DosBox for Android. I think they are talking about newer Windows games.

Re:Any practical use? (1)

ducomputergeek (595742) | about a year and a half ago | (#42791965)

More likely if your company has an older legacy winform app they use for something, say inventory database, it may have a real world "use" in being able to run the old app on a new tablet. Not saying it would be a good idea, but it might be able to be done.

The thing is, most of these "applications" are old enough to the point that they need to be rewritten from the ground up, especially for mobile devices in mind. Last two years that's what I've primarily been doing as a day job is taking custom software and writing backend API's into the database while another coder works on an HTML5/JS front end.

People can bitch and moan all they want about HTML5/JS, but when combined with Phonegap we've had pretty good luck with quickly developing CRUD applications that work on Chrome and Mobile Devices.

Re:Any practical use? (1)

zvar (158636) | about a year and a half ago | (#42791683)

Plenty, possibly not so much on phones (although I can still see some use there,) but on tablets a great use would be running something like Photoshop. Also the ability to run those fancy enterprisy apps that require windows. Games can work, but mostly strategy for lack of input. I would like to use my tablet and put on something like PC Stitch [pcstitch.com] and be able to use my low cost Android tablet, instead of having to buy a $1000 tablet just to run a couple of apps.

Re:Any practical use? (1)

HJED (1304957) | about a year and a half ago | (#42794175)

I can't imagine any computer experience worse, then using Photoshop without a mouse, it is far to fidely. Office on the other hand...

How about GNU software? (0)

Anonymous Coward | about a year and a half ago | (#42790681)

How about GNU software? I'd love to run KDE on my phones and tablets.

Re:How about GNU software? (2)

Desler (1608317) | about a year and a half ago | (#42790711)

KDE is not a GNU project.

Time to get Eric Trau (0)

Anonymous Coward | about a year and a half ago | (#42790923)

Maybe it's time to get Eric Trau [wikipedia.org] doing his dynamic recompile magic on some pesky x86 to ARM opcodes.

Probably not native binaries on ARM (4, Interesting)

vinn (4370) | about a year and a half ago | (#42791189)

Disclaimer - I haven't been actively involved in Wine development for quite a few years, but I used to be. Someone else will probably chime in and either correct me or give more details.

Running Wine on ARM probably won't run native Windows binaries. That means you're not going to be running MS Office on your S3 any time soon. To make it really work you'll likely have to specifically recompile the Windows app using Wine in the form of Winelib or do some kind of magic like qemu to get the big-endian / little-endian differences solved. That's on ARM though.

With Intel pushing their Atom platform, all of this would probably work out of the box, and it would probably actually work pretty good. Running the latest version of Photoshop or playing Diablo III might be a stretch on that platform, but realistically you could probably run a version of MS Office or enjoy tons of classic games.

Processor speed will be an issue - Wine has decent performance, but there's a lot of libraries that need to be loaded to make even a simple Windows app run. The latest quad core processors in the mobile world might be enough.

Re:Probably not native binaries on ARM (1)

toejam13 (958243) | about a year and a half ago | (#42792435)

So instead of WINE the environment emulator, the article is talking about WINE's less talked about feature, WinAPI emulation via a shared library (not unlike nt2unix [rwth-aachen.de] , windu [freecode.com] or Willows Twin [fsf.org] ).

I've actually used products like this before. It isn't much different than using libC instead of the native OS API. It makes porting from Windows to Unix so much easier. The only performance cost is the thunk to the emulated API. But if you want to port your Windows app to a big iron server (POWER or Sparc), it is the way to go.

Re:Probably not native binaries on ARM (1)

Jorl17 (1716772) | about a year and a half ago | (#42792521)

Just a little heads up. That library is called WineLib, and applications built with it also have to be run within Wine itself, I believe. (That is, they still need a wineserver, for instance)

Re:Probably not native binaries on ARM (1)

vinn (4370) | about a year and a half ago | (#42797015)

The other reply is correct, that you still need all of the Wine libraries after you port the app using Winelib.

However, there's a dirty little secret about Winelib... it doesn't necessarily work. Well, it could work, it should work, but it never gets tested. Wine has a fairly extensive toolchain itself, it has bits written in assembler and it requires other libraries, such as CUPS or until last week OpenSSL. Getting all of those pieces working nicely together requires maintenance and it really doesn't get any. Every couple of years someone will pick up Wine and get it running to some degree on SPARC or something, but there are no active daily developers doing any work with it. There's been merges for ARM in the last six months, but there's more work to be done there. Until a few years ago when the OS X port took off, Wine mostly only got used on Linux. There were some FreeBSD efforts, but really it was one guy who only occasionally had time to fix bugs the crept in on that platform.

The only advantage to actually porting an app using Winelib is to move to another architecture. That might be something of importance again with ARM emerging as a dominant force in the mobile world. Otherwise, if you're running on x86, skip a Winelib port and just run the native Windows app. The other advantage here is that Visual Studio will compile much more optimized Win32 code than gcc + Winelib (at least that was the case 6 years ago and I suspect it still is.)

Re:Probably not native binaries on ARM (1)

paugq (443696) | about a year and a half ago | (#42798251)

The only advantage to actually porting an app using Winelib is to move to another architecture

No, that's not the only advantage.

By using winelib, you can mix the source code of the Windows version with Linux libraries, which means you can incrementally port your application. I. e:
1. Start with a 100% winelib port
2. All winelib port but the database library, which you start using the Linux version
3. All winelib port but the database library and the DRM library ...

Re:Probably not native binaries on ARM (1)

BrentNewland (2832905) | about a year and a half ago | (#42793353)

I actually looked into the possibility of running Windows programs for x86 on other processors. Read posts with my name "BrentNewland" http://www.reactos.org/forum/viewtopic.php?f=2&t=11078&sid=9213440b9627ba56a8beb204022e2bae#p91132 [reactos.org] Same method applies to both WINE and ReactOS. In essence, you run the program on an x86 emulator (like QEMU). Supposedly little of the actual program is x86-specific, the majority is resources and Windows API calls. QEMU takes care of the platform-specific code, and any API requests are sent to Wine, which is compiled for the processor. That way it's not emulating the entire OS or the entire Win32API, which is supposed to allow performance up to 50% of native.

Android Emulator Sucks and Google knows it (1)

CuteSteveJobs (1343851) | about a year and a half ago | (#42791259)

> The performance problems though were attributed to running the Android environment emulated rather than showing off the Wine implementation from a bare metal device.

The Androids Emulator is a pile of shit. It is really, really slow. So slow I would describe it as unusable. Google knows this and have promised to speed it up, but in typical Google fashion they haven't done anything for many, many years. They are full of shit. Really. Android is cool platform, but Google don't understand developers the way {it pains me to say this!} Microsoft does. Google are irresponsive just like their useless emulator. Compare this with Apple's iOS emulator which kicks ass, but don't blame it all being a software emulation. The non-Google Bluestacks emulator runs faster than Google's piece of shit. It's so widely known that the Android Emulator is such a piece of shit I'm surprised WINE did a demo using it: It's like infecting yourself with pustular total-body herpes before a first date.

Typical posts:
"The Android SDK emulator is notoriously slow, and almost everybody hates it."
https://www.google.com/search?q=android+emulator+slow [google.com]

You appear ... (0)

Anonymous Coward | about a year and a half ago | (#42792741)

You appear to have an infatuation with the word "shit" :-)

Not for users (4, Insightful)

paugq (443696) | about a year and a half ago | (#42791307)

I'd say Wine on Android is not intended for the end user but for developers. It's not about running Windows x86 applications on Android but about porting Windows applications to Andoroid:

1. As the developer of a Windows application in C/C++, I'll take the source code of my application
2. I'll take the Wine SDK for Android (which does not really exist yet, but wait and see, wait and see!)
3. I'll compile the source code of my application using the Wine SDK for Android. Briefly explained, what this does is use winelib + bionic instead of bionic only.
4. Result is I get a native Android application with a reduced effort

I will of course need to take care about the UI, especially if my application uses Metro-styled custom widgets: those do not fit in Android, but it's a matter of porting the UI of that speficic widget.

So in summary Wine on Android looks more like a cross-platform library (such as Qt or Mono) that implements the Win32 API instead of some other API.

Windows RT apps on Android? I doubt it. Both of them are supposed to be ARM but "ARM" does not really mean anything: there are far too many variations of ARM, even amongst same-generation processors.

Re:Not for users (1)

Jorl17 (1716772) | about a year and a half ago | (#42792539)

"Wine SDK" = Winelib. Just plug in the fact that Android has no X11, fix a couple of dependencies, and there you go. BTW, you still need Wine to run Winelib applications (those are compiled with the Win32 API implementation given by wine, that is, they are native, but still require, for instance, a wineserver). It's all native, though.

But why? (3, Interesting)

markdavis (642305) | about a year and a half ago | (#42791397)

WINE is so hit or miss, and I don't think there is any MS-Windows app that would actually work in WINE that I would want to run on Android, anyway.

I would much rather have:

* OpenOffice/LibreOffice for Android. Far better chance of that happening (and actually working).

* A *FULL* X11 implementation for Android, bringing all (or at least many of) the Linux desktop apps over. (Again, far better chance than getting WINE working on Android with any reasonable performance or stability).

* Android apps running native (or at least semi-native) under a Linux desktop. (Really, this should be pretty darn easy, in theory anyway)

Re:But why? (1)

viperidaenz (2515578) | about a year and a half ago | (#42791553)

I'd rather have OpenOffice at least try to be competitive with Microsoft Office on x86 before they start looking at other platforms. If I wanted Office 98, I'd use office 98. I want something that can replace Office 2010

Re:But why? (1)

ChunderDownunder (709234) | about a year and a half ago | (#42791997)

Virtualization?

Wouldn't it be less work to
      - get kvm/xen working on your phone or tablet? The ARM v7a architecture defines virtualization extensions, paving the way to run Android AND Gnu/Linux simultaneously with minimal performance overhead (relative to one's 2GB quad core smart phone)
      - run android-x86 in a window via virtualbox? Less mucking around than porting desktop Linux to Android or Dalvik to Xorg?

Re:But why? (1)

HJED (1304957) | about a year and a half ago | (#42794203)

Um WINE is extreamly stable for MS Office, more stable then native LibreOffice in my experience.

Re:But why? (1)

donaldm (919619) | about a year and a half ago | (#42794737)

Um WINE is extreamly stable for MS Office, more stable then native LibreOffice in my experience.

I have been running OpenOffice and recently LibreOffice for almost 5 years now and never have had a stability problem. Of course my principle OS is Linux (Fedora to be precise) and I rarely have issues. The last time I ran Wine was about 2 years ago so I have not missed it especially since I can run MS Widows under virtualization and even then I rarely use it.

Re:But why? (1)

HJED (1304957) | about a year and a half ago | (#42794875)

Really, does your usage include docx? My principle OS is Linux (Ubuntu) and both LibreOffice and OpenOffice would consistently crash when editing that format, (as well as at least once a fortnight when not editing that format) I waited through a number of major updates over quite a large amount of time, but eventually I gave up and started using MS Office on WINE instead which I found to be more stable and had a more modern UI as well as opening docx documents correctly.

Re:But why? (1)

hweimer (709734) | about a year and a half ago | (#42794559)

* Android apps running native (or at least semi-native) under a Linux desktop. (Really, this should be pretty darn easy, in theory anyway)

Apparently, the WePad was doing just that [meegoexperts.com] , no idea how well it worked though.

Re:But why? (1)

donaldm (919619) | about a year and a half ago | (#42794691)

I would much rather have:

* OpenOffice/LibreOffice for Android. Far better chance of that happening (and actually working).

You have not done an app search recently have you.

A *FULL* X11 implementation for Android, bringing all (or at least many of) the Linux desktop apps over. (Again, far better chance than getting WINE working on Android with any reasonable performance or stability).

Why? There are around about half a million Android apps now that are much more useful than trying to implement X11.

* Android apps running native (or at least semi-native) under a Linux desktop

Actually many Linux apps are already available for Android. That includes LibreOffice, The GIMP, VLC, MPlayer, vi/gvim, Firefox, Google Chrome, Image and PDF viewers including games just to name a few.

Re:But why? (1)

TeknoHog (164938) | about a year and a half ago | (#42795939)

In other words, why don't we just have a proper GNU/Linux distro on tablets and smartphones, like Nokia used to do with their N series years ago. Jolla seems to be the only sane alternative to my trusty but aging N900.

As if my phone wasn't slow enough... (1)

d.valued (150022) | about a year and a half ago | (#42794053)

..now I'll have to worry about viruses? And popups? And even more poorly written software?

Ugh (0)

Anonymous Coward | about a year and a half ago | (#42794489)

Who would want to contaminate their nice Android phone with that crap

Here's what I want WINE on Android for (1)

Gumbercules!! (1158841) | about a year and a half ago | (#42794651)

While I don't expect this to kill the need for Windows - what I hope to get out of it (and I've done with this with WINE on a Mac, so I hope Android gets to this level) is the ability to run those annoying "Windows Only" management apps for virtualisation servers. It's "virtually" (some pun intended) impossible to properly manage VMWare, XenServer and Hyper-V without Windows. I managed to get XenCenter for XenServer running on OS-X with the Mac port of WINE, so if I could get it on Android and manage my VM farms from a tablet, it would save me carrying a laptop into our datacenter and... well... I dunno. I just want to do it.

Should work on Blackberry Z10 also. (0)

Anonymous Coward | about a year and a half ago | (#42796299)

If the devs don't move this to the new Blackberry, they should. If not, I can get teh binary and convert it to a blackberry binary in about 10 minutes. Sweet, so I get most of all Android apps on my BB10 and if WINE works also, I get all MSFT apps to! Awesome.

The future is looking good for the Z10.

RPi? (1)

Kadagan AU (638260) | about a year and a half ago | (#42797685)

With WINE moving to an ARM architecture, it seems reasonable that it could be made to work on the Raspberry Pi as well. I understand that this wouldn't be able to run any resource intense programs, but being able to run some of the less hungry windows apps on a Pi could create some interesting possibilities! I would love to see more progress made in this direction!
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>