Pandora Wine Working On N900 - Maybe Pandora?


trix said:
I wish I had a Pandora or other ARM device (and a bigger brain!) to help test this stuff with.

marovada: When you ran the x86 'ls' successfully, did it spit out the errors that Stuckie mentions?

Damion's post on the QEmu forum suggests he too is having problems with fork(). Maybe if one of you skilled coders hung out (with me!) in the #QEmu channel on freenode, they could help make this craziness work? Or at least get beyond the fork() problem.

I'm still trying to learn, so worst case scenario give me a couple months to learn C (I'm studying it now!) and a couple more to learn a bit of x86 Assembly, and maybe I can meaningfully contribute instead of just cheering you on and trying to play matchmaker.

Anyways good luck and I look forward to updates!

- trix

trix, yes ls spat out the same error but it still worked. On Damion's initial problems, I've also found this:

Qemu Mailing List
 
Last edited by a moderator:
mostly a shameless bump simply because I'm so excited about this but here's a little something to make this post a little on topic :D

will it be possible to emulate old school graphics cards (voodoo etc) in the future to go along with the qemu+wine combo? And will hardware acceleration be in the cards in the future?

thanks marovada and stuckie for your work on this!
 
MonkeyChops said:
mostly a shameless bump simply because I'm so excited about this but here's a little something to make this post a little on topic :D

will it be possible to emulate old school graphics cards (voodoo etc) in the future to go along with the qemu+wine combo? And will hardware acceleration be in the cards in the future?

thanks marovada and stuckie for your work on this!

I think you are expecting much better speeds with this than you should be... o.o Remember, the OP said that someone got basic windows programs to run and specifically mentioned solitaire as an example. Anything that needs a graphics card ≫ Solitaire.

-God Ginrai
 
Last edited by a moderator:
I know it will be slow at first but its still exciting. I spent a good part of my childhood on a p100. I don't expect games that require graphic cards to run, I don't even know if it will ever be possible, hence the question. Once someone gets it working on pandora I'll be testing up a storm, until then it's obviously all speculation but I prefer to see the glass half full.
 
Stuckie said:
Hopefully you'll get further than my little play about :)
Best I could get was wine.bin causing segmentation faults, and wineserver attempting to start but failing to do anything much...
I also couldn't chroot directly in, which was annoying as I had set up binfmt... though I was kindof doing this through a Debian chroot, so perhaps that extra level of abstraction was stuffing things up ( going from Angstrom > Debian-Armel > Debian-i386 ;) ) but if you do something like:
qemu-i386 /tmp/x86root/lib/ld-linux.so.2 --library-path=/tmp/x86root/lib:/tmp/x86root/usr/lib /tmp/x86root/path/to/binary ( think it's that, I'm typing from memory a bit so the ld-linux.so.2 bit could be wrong.. the library path is correct though - specify both the system and usr lib paths )
It does tend to work.. for the most part... /bin/bash will "work" but it won't fork() so it's utterly useless.
/bin/ls will through up unsupported syscall errors
/usr/lib/wine/wine.bin will just segfault and /usr/lib/wine/wineserver will attempt to do something, but doesn't seem to get much further due to forking as well ( if I remember correctly.. )

I haven't got much further. wine-pthread also throws a fork argument error if you try to start a windows binary with it. The segfault error is impossible to debug without gdb. It could be anything from a faulty .wine/config (eg because of required dll path) to an incompatible version of wine. I managed to run wine-pthread --version: I'm using 1.0.1. I'm wondering whether you need to use an x86 gdb to get anywhere with this. That may present other problems.
 
Last edited by a moderator:
*Dons asbestos cod-piece* I couldn't resist bumping this thread. I was hoping maybe there was some progress or any new info that could be shared by people in the know... Is there? :ph34r:

EDIT: I realise there probably would be a new post if anything had come to light, but maybe people forgot to post or something? :D
 
sold said:
*Dons asbestos cod-piece* I couldn't resist bumping this thread. I was hoping maybe there was some progress or any new info that could be shared by people in the know... Is there? :ph34r:

EDIT: I realise there probably would be a new post if anything had come to light, but maybe people forgot to post or something? :D

Excuse me if I sound like I'm firing a proverbial nuclear warhead at that asbestos cod-piece of yours, but have you seen the interesting advances that were made running Win 3.1 in DOSbox with a pandora screen resolution driver on it? It should be perfectly possible to install those old 32bit extension packs, and some people (I have on the PC anyway) got windows 95 running. This seems like a far more achievable goal - certainly in the near term. Also, what about the portability of BOCHS? I'm not an expert (how sadly obvious) but I'm more interested in a single layer of emulation (Qemu I think would work too) that you can run an actual O/S on top of, rather than farm some of the donkey work out to WINE to interperet (and probably break) some O/S functions whilst still having to emulate core CPU components with an underlying emulator (which could also break stuff).

My own dream, which I'm looking forward to someone testing before I actually get my Pandora, is to run a stripped down pandora O/S with the least amount of functionality possible to run DOSbox on top of, assign about 64mb to a ramdisk mounted as the C: drive and copy all the (again stripped down) O/S files from SDHC before booting windows from the C: drive. Only core 95 O/S would be installed, and I doubt it would take more than 25mb (since I once peeled windows 98 down to an entertaining 8mb win 95 should be easier) and the rest of the RAM on c: can be used for pagefile - speeding up the system and saving SD read/writes too. Any other third part programs could be installed to a D: drive mounted on SD of course. Surely this is a more feasible way to get things running horribly slowly in the immediate future?

EDIT: Uh oh - looking at your picture I think my nuclear warhead already made contact, sorry.
 
Last edited by a moderator:
From the time I tried it, Windows 3.1 wasn't terribly fast within Pandora Dosbox.

Plus, I'd rather not wait to boot up an entire second OS just to run the few simple apps I'm after.

It's good, and it's cool, but A Wine&Qemu option is equally good and cool.
 
Kind of an old bump, but any progress? Or is everyone stuck?

Thanks,

- trix
 
Take a look here with the latest wine update (1.3.4).

http://www.winehq.org/announce/1.3.4

- Winelib now supports the ARM platform.
 
Back
Top