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...
Offhand, I don't think winelib lends itself to use as a static library. We're rather heavily wedded to dynamic linking, more so than in the past. How bad would it be, really, to depend on the wine package? I'd be happy to help you think through the obstacles and see if that would work for you. (The Linux Standard Base people ask occasionally if Wine belongs in the LSB. If it were, you wouldn't have to worry about Wine being installed. Maybe next year Wine will be indispensable to make it to that state...) - Dan
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...
Offhand, I don't think winelib lends itself to use as a static library. We're rather heavily wedded to dynamic linking, more so than in the past. How bad would it be, really, to depend on the wine package? I'd be happy to help you think through the obstacles and see if that would work for you.
I guess I wasn't clear. I expect to need to depend on the wine package anyway. My understanding is that winelib apps need wineserver, so I wasn't looking for a monolithic package. 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. Or maybe I don't since wine brings a bunch of dependencies with it, but even still, I'm not sure how to provide a binary that would work on most distros so users don't need a 32bit build environment. This may not be a possible goal, and I can continue using the 'loader' lib for x86-64 builds, but wine brings a lot of advantages to my users (ability to do direct-install with wine, and ability to use the codes's built-in GUI configuration) so I don't like making those folks without the knowledge/desire to setup a 32bit build environment 2nd class citizens. (sorry if this message appears twice, I'm having mailer issues)
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. - Dan
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.
On Fri, Oct 24, 2008 at 9:13 AM, Alan Nisota <alannisota(a)gmail.com> wrote:
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
There ought to be a way. For starters, have you tried CreateFileMapping in wine, and mmap on the same file in the native bit? Sadly, linux does not use tmpfs by default, so the backing store writes would probably hurt performance. But it would be interesting to hear whether this worked at all.
Dan Kegel wrote:
For starters, have you tried CreateFileMapping in wine, and mmap on the same file in the native bit? Sadly, linux does not use tmpfs by default, so the backing store writes would probably hurt performance. But it would be interesting to hear whether this worked at all.
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, using a blocking socket to indicate data valid. I have only done it with a test application so far, and haven't worked out the details of timeouts and error handling, but this looks very promising. I've included the test app I'm using. It can be compiled natively and x-compiled using mingw32. Instructions for use are at the top. 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. Thanks for all your help.
On Sat, Oct 25, 2008 at 8:10 AM, Alan Nisota <alannisota(a)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.
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
Dan Kegel wrote:
On Sat, Oct 25, 2008 at 8:10 AM, Alan Nisota <alannisota(a)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
Boaz Harrosh wrote:
Dan Kegel wrote:
On Sat, Oct 25, 2008 at 8:10 AM, Alan Nisota wrote:
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.
If I were to do that, I wouldn't need a win32 executable. My goal here has been to find a way to distribute a binary (for those who don't have the means to build it) that will run on as many distributions as possible, and building a winelib app basically negates that purpose, since I can't build it as a static executable. This is all related to x86-64 as I said before. The question is: How do I make a system that has the minimal set of build dependencies for the user. He will need to recompile the host-app (mythtv, mplayer, xine) which is enough on a 32-bit platfrom to recompile my app. On a 64bit distro, he would need a 32-bit build system, which sets the bar much higher. My current plan is a hybrid approach. I will support 3 different ways to build the program: a) with the 'loader' code which has no dependency on wine. I'll stop providing the static binary that I've been using fox x86-64. This will be deprecated, and only for those folks who need coreavc but can't install Wine for various reasons. b) as a winelib app which requires a 32bit build env and wine to be available. I won't provide any binaries. This should be able to build on Mac, though I have no way to test it. c) as a win32 executable (uses mingw to cross-compile). I'll provide a binary executable for those who don't want to build it. This will only work on Linux as it depends on /dev/shm, but will work fine for x86-64. This should allow the most people to use the code with minimal effort.
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. The problem here is maintenance. I don't want to have to provide packages for every distro under the sun.
It should be noted that my user base is probably less than 50 people, so this is not, by any means, a large project. As such, providing Wine would be overkill. Nearly every distro has a means to install it. I really appreciate the help I've gotten here. Thanks.
participants (3)
-
Alan Nisota -
Boaz Harrosh -
Dan Kegel