Wine Running On A N900 (Maybe Pandora Too...)

[JayFoxRox]

You gotta be kidding right?

"ARM based superphone N900 running the x86 wine binary via a statically compiled arm qemu binary, within an x86 chroot."

So it's an ARM-based emulator of an entire PC (presumably a Linux based PC), running a Wine program which is emulating Windows programs.

No, it's probably not. You can use qemu to only translate the instructions, the system calls are still forwarded to the host OS. This is what my Pandora emulator does and also what others (Laurent thought about it [using qemu -> wine], and I was going to play with the idea soon [using qemu -> custom patched binarys]) thought about a long time ago already.

//Edit: God Ginrai, care to explain what "other parts" are emulated?

 

[God Ginrai]

You gotta be kidding right?

"ARM based superphone N900 running the x86 wine binary via a statically compiled arm qemu binary, within an x86 chroot."

So it's an ARM-based emulator of an entire PC (presumably a Linux based PC), running a Wine program which is emulating Windows programs.

No, it's probably not. You can use qemu to only translate the instructions, the system calls are still forwarded to the host OS. This is what my Pandora emulator does and also what others (Laurent thought about it [using qemu -> wine], and I was going to play with the idea soon [using qemu -> custom patched binarys]) thought about a long time ago already.

//Edit: God Ginrai, care to explain what "other parts" are emulated?

I was going to say standard graphics cards, etc. But I was not aware that qemu had such a mode as you speak about.

-God Ginrai

 

[aq21]

You gotta be kidding right?

"ARM based superphone N900 running the x86 wine binary via a statically compiled arm qemu binary, within an x86 chroot."

So it's an ARM-based emulator of an entire PC (presumably a Linux based PC), running a Wine program which is emulating Windows programs.

Not exactly. qemu-i386 is not a PC emulator. It is a Linux binary loader + x86 emulator. This means that it emulates x86 for running Linux user space binaries, but when the binary makes a system call, it is executed on the native ARM kernel, and not an x86 emulated kernel. This method also has

It is emulating a PC. To emulate x86, it needs to emulate the other parts of a PC that the x86 architecture uses to run.

You are wrong. Why argue when you don't know?

 

[SomeGuy99]

So if I get this correctly:

Qemu reads the binary instructions on the Windows executable.

Wine then looks at say, the API call to Windows, and invokes its own version.


So...

If you were running the Windows Calculator program, Qemu would be doing the arithmetic using recompiled x86->Arm, while Wine (the statically recompiled Arm version) would be sending and receiving messages to the application, and supplying a recreation of the program interface to the user (buttons, windows and stuff)?

Which means that Windows libraries are never once invoked, right? You get a performance gain by not having to run the entirety of Windows with Qemu?

 

[WizardStan]

If you were running the Windows Calculator program, Qemu would be doing the arithmetic using recompiled x86->Arm, while Wine (the statically recompiled Arm version) would be sending and receiving messages to the application, and supplying a recreation of the program interface to the user (buttons, windows and stuff)?

As I understand it, this is actually an x86 build of wine. You're basically right, wine receives the windows API calls and translates them to Linux API calls. That is still x86 code however which qemu must translate to ARM, introducing some overhead. Qemu then takes those linux API calls and makes native calls to the ARM libraries. So qemu is emulating the x86 instructions in the executable and in wine, but not the API calls. If I'm right in that assumption, some overhead can be eliminated and speed increased by building an ARM version of wine and combining it tighter with qemu.
This will almost certainly only be useful for programs that don't use DirectX though, I think. Maybe directSound or directInput, but the direct3D to openGL wrapper portion of it would definitely need some serious rewrites.

 

[SomeGuy99]

If you were running the Windows Calculator program, Qemu would be doing the arithmetic using recompiled x86->Arm, while Wine (the statically recompiled Arm version) would be sending and receiving messages to the application, and supplying a recreation of the program interface to the user (buttons, windows and stuff)?

As I understand it, this is actually an x86 build of wine. You're basically right, wine receives the windows API calls and translates them to Linux API calls. That is still x86 code however which qemu must translate to ARM, introducing some overhead. Qemu then takes those linux API calls and makes native calls to the ARM libraries. So qemu is emulating the x86 instructions in the executable and in wine, but not the API calls. If I'm right in that assumption, some overhead can be eliminated and speed increased by building an ARM version of wine and combining it tighter with qemu.
This will almost certainly only be useful for programs that don't use DirectX though, I think. Maybe directSound or directInput, but the direct3D to openGL wrapper portion of it would definitely need some serious rewrites.

It said in the linked article that this was x86 Qemu statically recompiled for ARM, so does that mean the Qemu Linux binary is natively ARM (albeit not custom written or optimised)?

Also, you say that API calls are translated from Windows to Linux API. What Linux API? That sounds a bit vague considering the modular nature of Linux. For example, i'm sure it uses X, and a Window Manager but not GTK or QT for widgets. Doesn't Wine use its own set of libraries for that? I thought they were used in non Linux systems like ReactOS?

 

[WizardStan]

It said in the linked article that this was x86 Qemu statically recompiled for ARM, so does that mean the Qemu Linux binary is natively ARM (albeit not custom written or optimised)?

Also, you say that API calls are translated from Windows to Linux API. What Linux API? That sounds a bit vague considering the modular nature of Linux.

I was intentionally vague because I don't know the exact details. Just some kind of wishy washy hand wavy "does the right thing" thing.

 

[SomeGuy99]

I was intentionally vague because I don't know the exact details. Just some kind of wishy washy hand wavy "does the right thing" thing.

I like that.

Okay, so all we need now is an Arm Wine port. I'm guessing it doesn't exist right? Or it's rubbish at the moment?

But yeah, running Wine in Qemu and the Windows binary must be all sorts of heavy overhead.

 

[Shaun]

Interesting project for novelty value, like running Windows CE on the Xbox. It could do bugger all, but it was fun to try. (Yeah, I realise you could get CE on the Pandora too.)

 

[SomeGuy99]

Interesting project for novelty value, like running Windows CE on the Xbox. It could do bugger all, but it was fun to try. (Yeah, I realise you could get CE on the Pandora too.)

Could it do bugger all because it only ran Windows CE binaries... which were usually in ARM or MIPS or something?

Yeah, I remember people waiting years for to see Windows running on an Xbox (yeah, I was one of those people). I've got Damn Small Linux, which I actually find useful for file transfering, but then the obvious finally hit me - I'm looking at a desktop OS in a really low resolution on a fuzzy tv screen. In the end, it wasn't all the amazing kinds of fun I thought it would be.

In the future I'll be looking back, wondering why on earth I wanted to run Windows apps on my Pandora, probably.

 

[Butterman]

Yay, Starcraft at 2fps ftw

On that note, anybody in the beta here?

I'm a 1400 plat zerg and I've love some more practice partners to rape

 

[Shaun]

Interesting project for novelty value, like running Windows CE on the Xbox. It could do bugger all, but it was fun to try. (Yeah, I realise you could get CE on the Pandora too.)

Could it do bugger all because it only ran Windows CE binaries... which were usually in ARM or MIPS or something?

Yeah, I remember people waiting years for to see Windows running on an Xbox (yeah, I was one of those people). I've got Damn Small Linux, which I actually find useful for file transfering, but then the obvious finally hit me - I'm looking at a desktop OS in a really low resolution on a fuzzy tv screen. In the end, it wasn't all the amazing kinds of fun I thought it would be.

In the future I'll be looking back, wondering why on earth I wanted to run Windows apps on my Pandora, probably.

Now that you mention it, I did end up running "Xubuntu" on my Xbox in the end. There was Knoppix too (I think) but Xubuntu worked better for me. Ran smoothly enough and I used my Xbox for internet browsing via Firefox. Worked a treat.

And yes, CE didn't exactly have much software available but there was also the fact the mouse driver was missing a cursor, making it difficult to use.

 

[Jeffery Mewtamer]

So we have two workers: gemu and wine

One translates x86 to ARM.
One translates Windows to Linux.

Together, they translate x86 Windows to ARM Linux.

And they do it with all the grace and coordination of a morbidly obese three-legged race team with no practice.

I think the real question is how well can both tools be reduced to their cores, united, and compiled for ARM so that both translations can occur as a single step?

 

[SomeGuy99]

So we have two workers: gemu and wine

One translates x86 to ARM.
One translates Windows to Linux.

Together, they translate x86 Windows to ARM Linux.

And they do it with all the grace and coordination of a morbidly obese three-legged race team with no practice.

I think the real question is how well can both tools be reduced to their cores, united, and compiled for ARM so that both translations can occur as a single step?

Both are slow and/or buggy. Combining the two is like mixing Wine and beer (just think of Qemu as the beer).

Just taking Wine as an example: It's slow to boot (22 seconds in the N900 video. It doesn't sound like a lot maybe, but if you're really interested in loading a Windows application and Wine isn't already initiated, that adds an irritating delay before your app loads). It's also slower than running natively in Windows, as you would imagine. You have glitches (for example try running Winamp and moving the window, it just dissapears. And Winamp is a pretty old and popular program) and often apps simply don't run at all.

Qemu doesn't run all that well from my experience. Running x86 on x86 is slower than say VirtualBox even though they are both virtualising. Why should it be slower? There must be some kind of overhead, or maybe certain parts are not optimised enough.

Running Qemu on my PowerPC Mac was a miserable experience- the G3 600 could barely run Dos. On the other hand, the Connectix Virtual PC program - a dedicated x86 to PPC translator - easily ran about 10-20 times faster. I actually ran XP and could load more than just solitaire. It seems to be constrained by slow disk access speeds and would choke when running multiple applications, but the actual CPU performance was freaking amazing.

To give you an example, I can run Winamp, in an emulated Windows XP on a ten year old Mac. I also ran VisualBoyAdance running a Gameboy Color game, and that ran (frameskip 2, with sound). That's an emulator within an emulator!

But Connectix were a talented team, and they used many PowerPC specific features to achieve this.

Now we just need Exophase to come in and tell us all why ARM can't cut it for the same task (I honestly do look forward to reading it).

B)

 

[Exophase]

Now we just need Exophase to come in and tell us all why ARM can't cut it for the same task (I honestly do look forward to reading it).

Fuck you, ARM is awesome

 

[SomeGuy99]

Now we just need Exophase to come in and tell us all why ARM can't cut it for the same task (I honestly do look forward to reading it).

Fuck you, ARM is awesome

Is it better than PowerPC? (Come on, I know you can do it. Give me a long and rambling explanation that I'll barely understand but find massively interesting anyway)

 

[Exophase]

Is it better than PowerPC? (Come on, I know you can do it. Give me a long and rambling explanation that I'll barely understand but find massively interesting anyway)

Okay, okay, I'll indulge you a bit. Pandora at 600MHz won't match your old G3 at 600MHz, but it shouldn't be that far off at most tasks. Probably at least 2/3rds as good in typical situations. The instruction sets themselves have various pros and cons over each other. I don't think PPC has any magic that gives it a huge edge in recompiled code.

I've heard similar anecdotes about Virtual PC on Mac before, amusingly enough another one included running VBA as well. At first I thought you said it was running a GBA game, which would have been really impressive, but GBC isn't really that amazing with that frameskip. It probably suggests somewhere around 12-18% native performance at best (something like a Pentium 75-100), although I could be underestimating VBA's inefficiency in running GBC games.

Just running an emulator within an emulator isn't automatically a big feat on its own. As someone else in this thread mentioned you can run Goomba on gpSP on PSP and it works well. If platform A emulates and full speed on platform B which emulates at full speed on platform C then transitive property blah blah blah etc.

Don't get me wrong, I'm sure Virtual PC for Mac (like Virtual Gamestation) was at the top of its game when it came to recompiler performance. That and qemu back then was probably not very good, especially targeting PPC. Things might be different now. Or not, I don't actually know...

 

[SomeGuy99]

I've heard similar anecdotes about Virtual PC on Mac before, amusingly enough another one included running VBA as well. At first I thought you said it was running a GBA game, which would have been really impressive, but GBC isn't really that amazing with that frameskip. It probably suggests somewhere around 12-18% native performance at best (something like a Pentium 75-100), although I could be underestimating VBA's inefficiency in running GBC games.

It's pretty amazing to me when Qemu can barely run Dos. When I say barely run, I mean even typing at the command line has massive lag.

Just running an emulator within an emulator isn't automatically a big feat on its own. As someone else in this thread mentioned you can run Goomba on gpSP on PSP and it works well.

Yeah, that was me. But it does demonstrate that both emulators are efficient right? I was saying that Virtual PC was so efficient you could run an emulator within it.

Don't get me wrong, I'm sure Virtual PC for Mac (like Virtual Gamestation) was at the top of its game when it came to recompiler performance. That and qemu back then was probably not very good, especially targeting PPC. Things might be different now. Or not, I don't actually know...

Ah yeah. The Qemu was a modern version, running on OS X Tiger. Obviously running OS X on an Imac G3 introduces overhead of its own, but it was easily 10 times slower. The Virtual PC was running in OS9 (for timeframe reference, I was messing about with this a few weeks ago, rather than years).

Are you sure that a G3 is more powerful than a Cortex-A8? I recall the G3 being compared to the Pentium 2 in performance, and tables showing the A8 is more comparable in MIPS to a Pentium 3? I'm sure you can tell me the correct information.

I can tell you that Linux on a G3 is a terrible experience. Maybe i've just been using horrible and badly optimised distros (Official Ubuntu PPC, Xubuntu, Debian) but it really is a poor performer. Based on all the vids so far, the Pandora Firmware is much faster and smooth.

 

[JayFoxRox]

Just taking Wine as an example: It's slow to boot (22 seconds in the N900 video. It doesn't sound like a lot maybe, but if you're really interested in loading a Windows application and Wine isn't already initiated, that adds an irritating delay before your app loads).

Wineboot doesn't even take a second for me. And it really depends on what you have in your wine install. I'm not even sure what wineboot does. In theory wine itself should ask for much initialization anyway as it mainly forwards calls to the host.

It's also slower than running natively in Windows, as you would imagine. You have glitches (for example try running Winamp and moving the window, it just dissapears. And Winamp is a pretty old and popular program) and often apps simply don't run at all.

No, wine+linux is not slower than windows. On my old PC it's faster in nearly every case. I didn't test it on my new PC but would expect similar results as this is what I often hear. Only some things which are not optimized yet or more complex things are slower. However, especially older games are usually way faster in wine than on windows.
Not sure about the winamp problem, but it might even be a problem with the window manager, not wine directly.

Qemu doesn't run all that well from my experience. Running x86 on x86 is slower than say VirtualBox even though they are both virtualising. Why should it be slower? There must be some kind of overhead, or maybe certain parts are not optimised enough.

Qemu was designed for simplicity (at least I found an PDF claiming that) and portability. Qemu was not really designed for x86 to x86 tho. I would assume Qemu does the full thing while VirtualBox takes some optimized route.

 

[Tempel]

Qemu doesn't run all that well from my experience. Running x86 on x86 is slower than say VirtualBox even though they are both virtualising. Why should it be slower? There must be some kind of overhead, or maybe certain parts are not optimised enough.

This likely has to do with the kernel modules that each uses for x86 on x86. Both Qemu and VirtualBox have modules that allow for more direct access to the hardware (aka virtualization, hence "VirtualBox"), cutting down the overhead by a huge amount. But depending on how you installed them, I think VirtualBox includes the module by default while Qemu's needs to be installed separately (it works without the module, just slower). Of course, none of this is relevant for x86 on ARM; direct hardware access isn't useful when the hardware is entirely different.