Winelib and static-build

[Alan Nisota]

Dan Kegel wrote:
> Alan Nisota wrote:
>   
>>> I have a project (http://code.google.com/p/coreavc-for-linux) which is a
>>> linux executable which provides access to Windows DirectShow filters
>>>
>>> The problem is that I normally provide a static binary so that users on
>>> x86-64 can install it easily without needing a 32bit build environment...
>>>       
>> I expect to need to depend on the wine package anyway.
>> What I was looking for is a way to supply an executable
>> that will run on any distro that has wine installed already.
>> However, as I said, it must be a winelib app, and I
>> need to statically compile in libc, and librt to make
>> a build that 'just works' on x86-64 distros.
>>     
>
> How about making the win32 part of your app a real
> win32 .exe that just runs with Wine, and uses
> commandline / environment, pipes, or sockets
> (or maybe even shared memory) to communicate with the native part?
>
> The problem with shipping winelib apps is that
> IIRC winelib is not a stable ABI.  win32, however, is.
>   
Well, the entire app could easily be a Win32 executable, except that I 
need to be able to communicate with a linux app via shared memory.  The 
app is basically just an interface to a directShow filter, and that 
filter does a lot of work on large memory ranges (normal input per/frame 
is <100kb, output is ~4MB at 1920x1280) with this communication 
happening up to 60 times per second.  There is a measurable performance 
hit to making copies of that memory; I measured it at about 5% before 
switching to the shared memory implementation, and one of  the main 
reasons that people want to use this app is to squeeze enough 
performance out of their machine so they can watch their HD BluRay (or 
whatever) videos on hardware that is not up to the task with ffmpeg.
So I'd be happy to have a win32 app that can talk to linux via shared 
memory (I also need semaphores, but that could likely be handled via 
socket communication) but I don't think this is possible, and so I seem 
to be stick with either using winelib or continuing to use my hacked 
'loader' implementation.