Hi Friend

I did it. It's my mistake on some operation. Thank you very much!

Best

Hi.

Thanks for the tarball.

It works quite well for me as well.

Do you mind telling us how you built this wine? Is there any special options that has to be enabled or disabled? Or is it just a simple ./configure && make?

Also, any special patches needed? And is that a straight x86 build?

And what about versions of wine? The version from you is 0.9.14. I'm interested in trying a different version of wine too.

Thanks!

FWIW, I've successfully built my own wine, using 0.9.14 source. Plain x86 native build, and managed to run it with the qemu-i386 you provided.

The only extra bit is I had to update my libs (things like X libs, gtk, etc) from my build tree

Got a question regarding wine versions.

While 0.9.14 kinda works, it's pretty old. I tried using newer versions, but they don't split the binaries into wine and wine-pthread anymore. Looking at the changelog, the default should be using pthread, but then when I try to run it, it seems to behave like the "wine" binary of 0.9.14, which doesn't run at all.

Perhaps I haven't been following this thread completely, was there a reason why only wine-pthread works, but not wine?

Thanks.

(Am I the only one still playing with i386 + wine now?)

You probably are buddy This is pretty old I still play with it each time in a while but no too much.
If I am not wrong a newer version of wine requires NPTL which doesnt work with qemu (it apparently does with newer versions such as 1.0 or 1.0.1 of qemu where you can force it in the configuration but they dont compile good with the old C compiler/library, havn't looked into it much though, if you compile tell me). Take into account the new wine executable has the wine-pthread shoved into it so running an old wine-pthread is like running an old wine executable which with newer libraries might go all crazy on you.
wine executable is a whole loader that has a way of launching the other apps that qemu doesn't like (just as wine-pthread will not launch wineserver wine will not launch the other). Of course i am no expert at this, just thought it might help .
If one digs into the wine-pthread code of wine 1.0.18 or 17 (the last version with wine-pthread) and the new wine they might be able to recode it so that launching it with a new parameter (such as --do-pthread or something shorter) it acts as an old wine-pthread but with new features. I am just speculating as I have not looked into the code of any.

So basically if you compile a newer version of qemu against the old N900 glibc then newer wine and the wine command might work, if not one needs to edit the source of the wine executable to get it to work. Does this make any sense or have I made it more confusing??

Well that video is indeed very interesting and promising. Is there any more information of such a project anywhere else?

I am mailing them, probably a newer or patched QEMU, that's all

I would say it's not the same, it says to be using binary translation, which means that the x86 binary has been converted to ARMv7 code previously and thus, execution speed is much higher.

I believe Wine for ARM is available on the repositories and is not something new, I believed they were running real x86 apps without conversion or recompilation or whatnot. If I am mistaken then if they use some cool binary translation then, if it works, it would give higher speeds than the QEMU patchy hack we use

Hey guys.. I got an email from One Laptop For a Child over this and told them to go here!

We actually did help someone!