Computing desk
< April 12	<< Mar \| April \| May >>	April 14 >

Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.

April 13

Converting Windows programs

Is there any software tool etc. available on Net using which one can convert a Windows .exe (standalone) program into an app that can be run on an Android phone or tab ?210.56.125.60 (talk) 14:32, 13 April 2016 (UTC)[reply]

No. The executables are too dependent on the Operating System. So, instead, there are virtual Operating Systems that attempt to mimic the Operating System and run the executables (slowly). 209.149.113.15 (talk) 15:04, 13 April 2016 (UTC)[reply]

Eh...careful '209. Maybe...just possibly...it can be done.

There are at least three fundamental issues here. One is that the CPU in an Android phone doesn't understand the machine code language of an x86 style CPU. The second is that Andoid is based on Linux - and Windows is not - so the underlying operating system is utterly different. There IS a software package for Linux (called Wine) which allows Windows programs that are written for the appropriate CPU to run under Linux - but Wine isn't actually available on Android. Thirdly, the lack of a mouse and keyboard on most Android devices would prevent you from meaningfully using the software on a touch-screen device. Things like drag-and-drop and the scroll/center/right buttons of a mouse don't really translate well into a touch-screen environment.

So you'd need an Android device with an x86 CPU to which you could connect a USB keyboard and mouse. Then there would have to be a port of Wine to Android.

Well, that can be done: HERE - but as far as I know, it's not widely available yet.

See also THIS and THIS which are both 2015 reports that say "It'll be out by the end of the year" - although I don't think it is. SteveBaker (talk) 20:38, 13 April 2016 (UTC)[reply]

In my opinion, it is a semantic argument to say "Wine is not a virtual operating system". If you say it isn't, then my answer would be: No. You can't run a Windows program on Android. You need some sort of translator program in the middle that acts as a slow virtualization between the Windows program and the Android operating system. 209.149.113.15 (talk) 12:39, 14 April 2016 (UTC)[reply]

I don't care. The answer to our OP's question is "Maybe, soon - check out crossover/wine." - and not "No". SteveBaker (talk) 13:17, 14 April 2016 (UTC)[reply]

I know very little about WINE and wine, but I believe that it does not "convert a Windows .exe (standalone) program into an app that can be run on an Android phone or tab", but instead allows you to run a Windows executable on Android without converting it. It is very possible that I am wrong, and of course this is nitpicking. The Quixotic Potato (talk) 18:17, 14 April 2016 (UTC)[reply]

Define 'slow'. If you look at reports of FPS comparisons of games on Linux with Wine vs on Windows, in some cases the games perform terrible or have major issues due to compatibility problems. In some cases they work but with a fairly major performance hit e.g. [1] seems to be about 50% or so lower. In other cases they work fine with only a small performance hit. Some people even report higher FPS than in Windows. I wouldn't entirely trust some of these reports, and since Android x86 tablets are only likely to have some very low powered Atom (although the same Atoms are also used for some Windows tablets sometimes even with dualboot) you shouldn't expect much modern fancy 3D PC gaming from them. And beyond the lower speced hardware, there would be a number of additional problems for Android, e.g. the OpenGL available on Android AFAIK tends to be a restricted subset and I wonder how well Wine would work with the Android drivers which would probably be a bit diff from normal Linux ones too. But no one mentioned gaming before me anyway. While it may not make much sense, I wouldn't be completely surprised if some sort of simple artificial benchmark or similar (e.g. Prime95) performes not that far from native. (Remember my earlier point, with some tablets you could test this if Wine on Android really existed.) So the question remains, what do you mean by slow? Nil Einne (talk) 17:29, 14 April 2016 (UTC)[reply]

Wine is not as slow as a full-blown emulator. That is clear. Wine is not an emulator. Wine sends x86 operations to the x86 processor - which is why it is not an emulator. However, most Windows executables require basic Windows OS system calls, DLLs, etc... Those are implemented in a way that they are not really Linux system calls and not really part of the Linux OS at all, but an add-on layer that does whatever possible to try and figure out how to make the Windows executable do something useful. Wine developers claim that they are not emulating the Windows OS or DLLs. They are providing an alternative layer that sits between the Windows executable and the Linux OS (and, if possible, bypassed the Linux OS all together). I claim that sending code through an extra layer will slow it down. I don't think I'm making a controversial claim. I know there will be anecdotes where my claim is wrong. But, overall, sending code through an extra layer makes the executable run slower. Further, this is drifting very far from the question: Can I convert a Windows executable (not source code - the executable) into an executable that runs on Android? No. Not right now. In the future - maybe. Right now, this exact minute - no. 209.149.113.15 (talk) 19:44, 14 April 2016 (UTC)[reply]

The problem is it depends on what you mean by an extra layer which you never defined and is rather unclear in the context of your reply or this question. In your latest reply you touched on this a bit, but you seem to have confused the question even more. First it should be noted you said slow and slowly originally rather than slow it down or some other wording. Perhaps it's just me, but when someone says something is slow, I'm thinking a significant speed loss (perhaps 50% or more) rather than simply a minor performance hit.

Anyway probably most software would theoretically be fastest if you had no real OS or any other extraneous code and your code was perfect. But in practice this isn't what most software is like. So how do you define an extra layer. Historically Windows software has run on two different kernels, the NT one and the 9x (DOS derived) one. (AFAIK, Windows CE never supported Windows apps unless they were specifically designed to be cross platform.) While rare, some people are still using software which was designed for 9x. Is running Windows software on either of these OSes running with an extra layer? Is running software on ReactOS running with an extra layer compared to either of these two examples? How about running on some variant of Linux with WINE? What about running on some Linux derived OS which uses the Linux kernel but with anything unneeded for Wine removed? How about if you modify the kernel, WINE and any API features to optimise performance? How about if I do all that for one specific piece of software? What APIs are we referring to anyway? For legacy reasons, Windows has a heck of a lot of them. To put it a different way, if your claim is uncontentious, why do a number of *nix supporters like to claim that Windows software runs faster and better on Linux when there are no compatibility problems because the Linux kernel and perhaps the WINE implementation of the various API is better? (Something which I don't think is correct, but illustrates the point that there are a whole bunch of people who disagree.)

Also is comparing it to running natively on Windows even correct? In a dual boot scenario perhaps, but if your only OS is Android, your options are either running Windows on a virtual machine, running the Windows exe through some API compatibility later, or running native Android code. We know stock Android software uses the Java based framework although with the support for native code and such advances. Traditionally the Dalvik (software) was used but this was replaced with the Android Runtime which uses AOT; and this change was made at least partially for performance reasons. If someone ports your software to Android which as discussed is the third way you can use it on Android, how good is the port going to be? Even if it's a good port, how will performance actually compare particularly if you're still using Dalvik (most Android versions before 5, which due to the nature of Android some devices are still using although probably not many x86 ones). I have no idea what the plans to implement WINE on Android actually are, but it seems possible some of them will require some degree of changes and rooted devices and largely bypass the traditional Android framework. So again, how do you define slow? Is the performance using your WINE (or whatever) on these devices even going to be worse let alone significantly worse than the performance on Dalvik even with a good port?

I do agree this is offtopic, but you're the run who kept insisting it would be slow or slowly but haven't really provided anything to back this up.

I also question the claim it's not possible at the moment. A simple search found [2] [3]. I doubt the performance of this is very good, and the list of supported software appears to be one plus one in progress and that's after 4 years (actually I'm not sure if there's been any real work since 2013) [4], but it sounds like this is really allowing the EXE to work on Android by patching the API calls and instruction set. (Rather than reimplementing the engine ala ScummVM, Exult, Ur-Quan Masters, OpenXcom etc which I agree is different.) In fact traditional it worked in a manner very similar to the OP's question although they've now moved on to dynamic recompilation. [5]. I think there's also the open question of where you draw the line. For example, since you can run QEMU or other emulators on Android [6] [7], you could theoretically make something which would take the EXE and add QEMU and some Windows compatible OS (perhaps Windows itself although I doubt this will comply with any EULA) and produce something for Android. There appears to be some discussion of a more complicated variant of that here [8]. Even the simplistic example is far from trivial so by that token doesn't exist yet, but simply running Windows 98 on Android sounds to be a bit easier although is likely to be very slow. [9]

P.S. I've mostly assumed 9x or later here. Of course Windows 3.1 is still Windows and still had exes and would probably work on DosBOX or Bochs. (See earlier for example.) I quite doubt this is what the OP is referring to, actually I doubt they're even referring to applications for 9x, however it also IMO illustrates the problem with an unqualified no.

Nil Einne (talk) 15:42, 18 April 2016 (UTC)[reply]

There are two issues that keep getting jumbled up here.

1) The original question asked if there was a program that would turn an exe file into an Android app. The original question did not ask if you could run an exe file on Android. It asked if you could convert an exe file to an Android app. While I am certain that there is a way to convert a trivial "Hello World" exe file to an Android app, you cannot convert any exe file to an Android app. For example, you can't convert Internet Explorer into an Android app. (I am assuming IE is run using an exe file and not a com file or something similar.)

2) I made a horrible mistake of mentioning the use of emulator software. I say "emulator" to mean "a program that lets you run software for one operating system in another operating system." If there was a Windows emulator on Android, you could run some exe files on Android - but it would not be converting the exe into an Android app. The emulator is the Android app. The exe file remains an exe file. As for why it is slow - you are executing more instructions to emulate the operating system. For any non-trivial program, you will use code that is not part of the main operating system but is part of the emulated operating system. The more instructions you send to the CPU, the slower the program will be in a general case. I am not saying it will be 50% slower. I am saying it will have more instructions to execute and each instruction takes time, so having more instructions to execute will make it slower. Add to that the already slow CPUs inside of many mobile devices and the hit from emulation is worse than on a modern PC. I don't personally see the issue with this concept. I do understand that there are hundreds of trivial cases where the exe instructions do not require any sort of emulation and run basically as a native application. I seriously doubt the original question was about those trivial useless cases. It was about real Windows software that people normally use, such as Internet Explorer, Outlook, and the Microsoft Office suite. (And guess what kind of Windows software doesn't run on Wine.) 209.149.115.199 (talk) 16:27, 18 April 2016 (UTC)[reply]

OT: is there a single word for "having even a rough idea regarding what is doable" in an engineering context? Asmrulz (talk) 11:15, 15 April 2016 (UTC)[reply]

Most software engineers split the problems of the world into "doable" and "non-trivial" (which means "impossible"!) - this makes it unnecessary to have a rough idea - it's either doable or it's non-trivial and that's that! :-) SteveBaker (talk) 17:35, 15 April 2016 (UTC)[reply]

And most IT managers (I generally call MBAs) ask "Can it be done?" and think that "Yes, it can." means "Yes, we can do it before the end of the day." That is the reason we need simple "It is doable" and "It is not trivial" answers. I assume Mr. Baker is one of the few who could say, "Yes. It can be done, but we aren't stupid enough to try and do that." Most programmers I meet are treated like code-monkeys and can't give answers like that. 209.149.113.15 (talk) 17:50, 15 April 2016 (UTC)[reply]