Dan Kegel wrote:
On Sat, Oct 25, 2008 at 8:10 AM, Alan Nisota alannisota@gmail.com wrote:
Very cool. Here is what I did: In linux (host): use shm_open and ftruncate to create a shared-memory region (this will be at /dev/shm/<name> in linux) use mmap to map that into memory create a socket to use as a semaphore
In the windows executable: use CreateFile to open Z:\dev\shm<name> use CreateFileMapping and MapViewOfFile to map that into memory open the above socket
I can now pass info back and forth between wine and linux via shared memory,
Sweet! I had forgotten about /dev/shm.
If your going the win32 executable way. then do something much easier here. Create a winelib (plugin) DLL that exports a stable API to your win32 application. But then, since it is a winlib dll project you can use any Linux native API easily. Be it /dev/shm or what ever you want. But you get to use pure Linux API.
This will also solve your below problem.
The next question is whether this can be made more portable so it could be used on Mac as well (I've yet to be able to make my loader work on Mac, and this theoretically could if I could figure out how to use something like tmpfs there). I am not knowledgable about whether BSD/OSX has anything equivalent to tmpfs.
I just looked a bit, and it doesn't quite look like MacOSX's shm_open creates a visible file in the same way it does on Linux. So I'm not as optimistic there...
- Dan
In MacOSX have another implementation for your plugin winlib DLL and so a plugin part for your application. Here using MacOSX native API.
After saying all that. I don't share the wine guys opinion about winelib. I think you can have a very tight operation with a winelib project. You will see that it is very easy to package a private copy of wine and with use of a private WINEPREFIX in scripts you get a nice private operation that is not influenced from any wine installation in the system. You start with a full wine self-compiled installation, then it is very easy to just delete anything your winelib app does not use. Once you have your minimal set of wine dlls/exes, You check out their Linux dependencies and individually tweak link options for full control over outcome. And since you have your own compiled copy of wine the API stability is your own choice.
Just my $0.017 Boaz