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.You can symlink any folder to "~/.wine/dosdevices/x:" where x is any letter not already used and not /.Is it possible to at least put this drive_c folder on an SD card?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.
.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
Hum, too bad, I'll arrive there not before Friday afternoonMaybe 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.
1. Ok1. 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.
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 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.
Come here you I got a big ol' smoochiewoochie for you for being so awesome! :wub: :lol: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.
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.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.
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?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.
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 winerootWhen 3d Passthough Work on Qemu itself,can you Release that then?
I will Try Descent 3 Linux X86 Version then with that
not nonsense, that is brilliantI 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.