Apps Port Wine to Android

[rogercruz]

Hi Bob,

Actually, I think the x11 mapping to Android is the hardest part as I see it. As you pointed out, the x86 instructions can be run natively on x86 platforms or on QEMU on non-x86 platforms.

Roger R. Cruz

 

[Bubsmash]

It would technically be better to take from what the Wine guys did and totally redo the code and everything to suite the android phone. I am not saying that it would not be possible but for practical reasons I think it would be better to start a whole new project that builds off of Wine for android.

 

[king001]

Hi everyone im new here. I know no one has commented on this since last year but i had a thought. Windows 8 is being designed to run on arm architecture, im not 100% sure whether its confirmed that x86 'legacy' apps will be able to run on on the arm cpus BUT if that does manage to happen -performance drops aside, i think it may give android developers some encouragement to do the same on android. It would be handy for programs that require minimal cpu use in x86 anyway. I mean crysis is never going to run on a current arm cpu anyway.

This might be comparing apples with oranges in terms of what i just said but garage band is a program that runs fine in both osx AND ios albeit they have different ui's but at a base level, they record audio and even playback midi sounds -relatively mundane tasks for a cpu but you get my point.

Like i said, just a thought

 

[mastiffman93]

Remember, Windows wasn't always a 32 bit OS; when microsoft started up, they were coding in a 16 bit OS (ex. MS-DOS). So if you can emulate a microsoft DOS environment, I believe you could still make it work, just not 32-bit.

 

[codeguru]

Windows 8 is being designed to run on arm architecture, im not 100% sure whether its confirmed that x86 'legacy' apps will be able to run on on the arm cpus

When MS releases a CPU emulator for non-X86 CPUs, then Windowx 8-X programs might work - but probably 90% slower than original.

Most Dot net apps might work, same as Silverlight or any other "interpreted" languages like Java because they are more or less architecture independent if there is a runtime for it. But then these apps must be pure, and a single processor-dependent dll (e.g. copy protection) might ruin your day.

Long time ago I played around with cross platform emulators. E.g. 1997 there was a 64 bit DEC Alpha CPU (21164) euipped PC sold coming with NT, having a "code translator" which converted some apps successfully so they could be used on the Alpha-NT natively. These translated apps like Word or Powerpoint ran fairly quick, and there was an emulator as well - and that was very very slow. Mostly intended for legacy.... anyway the DEC Alpha Windows project was some funny exotic stuff and discontinued after NT4.

Apple did the same, there was an X86 emulator for the first power PCs in 1995 but during that time the CPUs had about 100 MHz - equipped with IBM PowerPC 64 Bit CPUs. There also the emulation speed was so damned telrrible slow that Apple decided to develop a slot-in card having a complete 486 DX2/66 board on it..... there was also a working emulator for the older Motorolla 68040 based Apple computers, also too slow for software from that age. That was ok for running some DOS apps because during that time many many peoople worked still with Word Perfect for DOS and Clipper... a forgotten script language like Java some years later.

I assume that the Tegra3 Quadcore and the Lenovo Quadcore CPU can run simple stuff quick enough... if developers put together the stuff - WINE and QEMU or build a virtualized X86 VM with CPU emulation.

Anyway, WINE is just a WIN32 compatible API and that won't be able to run programs requiring things like Visual Basic runtime or C++ Runtime. Many of the "old school" programs from Windows 95 or NT times were done with C++ Runtime 6 or MFC 4.2

The same way was taken by the Mono project, emulating Dot Net 2 on Linux, but never complete enough for professional use.

Probably someone diggs out the code translator technology used in NT 4.0 for Alpha CPUs and adapt it for Android and StrongArm or Tegra, there should be no technological challenge to do this. MS did that 15 years ago, translating X86 Code to 64 Bit Alpha CPUs, CISC to RISC but MS didn't have to face a different API as a target. Anyway, Win32 and Linux (and Android of course) API calls concerning the GUI are not so different as some might think.

I once handled a program, that could be compiled on Windows AND on Linux as well, showing the same GUI on GTK and on Win32 - and some of the calls, especially for making GUIs, adding menu items and so on were very similar

I am personally interested to run a Windows 95 dictionary app for mongolian language on Android, because the developer don't want to port it. Unfortunately I have no time to do a "Win32 on Android" by myself and I doubt that there might be enough interest.

As somebody else mentined, there are four ways:
-Citrix client
-RDP client
-VMware View
-VNC
to see a program running elsewhere until the Win32 on Android thing works in a way that you cold start Word 6.0 or my favorite: Sokoban for Dos 2.1 - which doesn't work anymore on Windows 7 (no 16 Bit support)