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.