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.