Winelib and static-build

[Boaz Harrosh]

Dan Kegel wrote:
> On Sat, Oct 25, 2008 at 8:10 AM, Alan Nisota <alannisota at 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