Release WINE


5. Put a program in ~/.wine/drive_c/ and run it.

<snip>

You can't run EXE files from arbitrary locations. A parent folder (other than /) needs to be a dosdevice.
Is it possible to at least put this drive_c folder on an SD card?
You can symlink any folder to "~/.wine/dosdevices/x:" where x is any letter not already used and not /.

.wine ends up decently big by itself, so you should probably put the whole thing on an SD card via something like: mkdir /media/any-sd-card/wineprefix; ln -s /media/any-sd-card/wineprefix ~/.wine
I don't get the WinePrefix, but then I've not used Wine since .... urm.... a very long time ago. Need to have a proper look at this, though not sure if it'll be tonight now.

Thanks anyway, I'm sure I'll post if I get stuck ;)
 
Maybe i come to Gamescom,but i promise nothing.


There is a chance that i can come on Thursday.


When then bring i lot of Qemu Things with :)


But i cannot Promise that.
 
Maybe you can make a install PND for Users who run from SD Card the OS.

They have enough Space on SD :rolleyes:

Edit: Just downloading your Wine,i am Curious ;)
 
Last edited by a moderator:
Cool ... maybe my most favorite game of all times (Interstate '76) will be playable with this on the Pandora after all? But I already had major problems to make it run on my Desktop PC using WINE (not due to performance though, it just crashes a lot). There are some other games like "N.I.C.E." that might work as well ... guess I'll have to find some time and fiddle around with it under Slackware :)
 
1. Extract to a linux (ext3 etc, not FAT) partition (NOT to /, put it in your home folder or something).
2. Run prep.sh.

3. Add /usr/local/wine/bin to your PATH.

4. Run `wine wineboot`

5. Put a program in ~/.wine/drive_c/ and run it.

6. Enjoy.
1. Ok

2. Have under Slachkware Errors with line 4-5-6 or near,i dont searched what that Errors say

Tried it with sudo with gksu and as su.

3. How do i add them in my PATH and what it my PATH?How can i edit my PATH?

Have that anyone to do with that LD Library Path Command?

4. Did not work,i think because that unknown Error Messages.

I install now Bodhi Linux and try it with Bodhi ;)

Just starting from Step one then :D
 
Last edited by a moderator:
I got a passthrough syscall working via Qemu:


aegis@rebirth:~/precise$ tmp/a.out
Entering passthru
func(1)(3.14, local memory test)
Finished passthru
Magic words.
What happened here:

I called a special syscall from an x86 program running against Qemu.

I passed a pointer to a struct containing the function name (1) and arguments (a floating point number and a char pointer back into the x86 memory), as well as a return value char **pointer.

The Qemu code (back in ARM space) printed the function args perfectly. This means I can access pointers from my syscall with no problems. I was also able to pass a string "Magic works." back from ARM land to x86 via the return pointer.

This is everything I need to wrap OpenGL. I will link libGL into Qemu and provide a shim library in x86 that proxies all data through the syscall.

This is mostly a code generation task, which I already have a great framework for. I might have something to show in the next 12 hours or so.
 
Last edited by a moderator:
I got a passthrough syscall working via Qemu:


aegis@rebirth:~/precise$ tmp/a.out
Entering passthru
func(1)(3.14, local memory test)
Finished passthru
Magic words.
What happened here:

I called a special syscall from an x86 program running against Qemu.

I passed a pointer to a struct containing the function name (1) and arguments (a floating point number and a pointer back into the x86 memory), as well as a return value char **pointer.

The Qemu code (back in ARM space) printed the function args perfectly. This means I can access pointers from my syscall with no problems. I was also able to pass a string back from ARM land to x86 via the return pointer.

This is everything I need to wrap OpenGL. I will link libGL into Qemu and provide a shim library in x86 that proxies all data through the syscall.

This is mostly a code generation task, which I already have a great framework for. I might have something to show in the next 12 hours or so.
Impressive work!
 
I got a passthrough syscall working via Qemu:


aegis@rebirth:~/precise$ tmp/a.out
Entering passthru
func(1)(3.14, local memory test)
Finished passthru
Magic words.
What happened here:

I called a special syscall from an x86 program running against Qemu.

I passed a pointer to a struct containing the function name (1) and arguments (a floating point number and a char pointer back into the x86 memory), as well as a return value char **pointer.

The Qemu code (back in ARM space) printed the function args perfectly. This means I can access pointers from my syscall with no problems. I was also able to pass a string "Magic works." back from ARM land to x86 via the return pointer.

This is everything I need to wrap OpenGL. I will link libGL into Qemu and provide a shim library in x86 that proxies all data through the syscall.

This is mostly a code generation task, which I already have a great framework for. I might have something to show in the next 12 hours or so.
Come here you I got a big ol' smoochiewoochie for you for being so awesome! :wub: :lol:
 
You found a maybe working Way for GL Passtrough????

Geniouss :D

I dont know much about that but i understand the Results.

Wow this can maybe make Windows 3D Games Possible with Wine ;)

And with Qemu much more 3D Games.

I cant await Unreal Tournament and Descent 3 :) :)

When 3d Passthough Work on Qemu itself,can you Release that then?

I will Try Descent 3 Linux X86 Version then with that :)
 
Last edited by a moderator:
you%5C%27re%20awesome.jpg
 
soawesomerai.jpg


So you have some kind of address translation between the qemu system and host system? Like 0xAA in qemu space is the 0xBB in host memory? Do you have a table for it, or has qemu one you are using? I am total noob in virtualisation.
 
Last edited by a moderator:
So you have some kind of address translation between the qemu system and host system? Like 0xAA in qemu space is the 0xBB in host memory? Do you have a table for it, or has qemu one you are using? I am total noob in virtualisation.
No, the point of this test is that I need ZERO address translation :) . Pointers work perfectly from either side on either side of the emulation layer.
 
Last edited by a moderator:
No, the point of this test is that I need ZERO address translation :) . Pointers work perfectly from either side on either side of the emulation layer.
How does this work? qemu has its own kernel, or? How does it not write in to space, which is reserved by the host kernel? Isn't there some kind of hypervisor?
 
When 3d Passthough Work on Qemu itself,can you Release that then?

I will Try Descent 3 Linux X86 Version then with that :)
My qemu-i386 binary and gnemul package will work for any Linux x86 binaries, provided you have any extra required host libraries available. I just so happen to ship WINE with it and call it wineroot ;)
 
Last edited by a moderator:
I wonder if this passthrough magic could be applied to other libs, too.


Like grabbing SDL calls from a Windows SDL game and running them natively with the ARM SDL on the Pandora instead of an emulated Windows environment DLL.


On the other hand: It is early morning and I might be talking nonsense.
 
It's absolutely possible for Linux dynamic libraries. I'm going to do it with alsa to fix sound. I'm not sure how useful it will be for native Windows libs.
 
I wonder if this passthrough magic could be applied to other libs, too.


Like grabbing SDL calls from a Windows SDL game and running them natively with the ARM SDL on the Pandora instead of an emulated Windows environment DLL.


On the other hand: It is early morning and I might be talking nonsense.
not nonsense, that is brilliant :)
 
Back
Top