On Sat, 2005-05-21 at 00:43 +0900, Mike McCormack wrote:
IMO, the right way to make it work is to enable closer integration of the two projects. We tried Mono using Wine, and that failed, but Wine has so far not tried using Mono.
That's a big failure on our part (as well as theirs). Doing it the other way around is not scalable, there are many projects that can potentially use Wine. We need to fix this properly.
The problem is that the only "official" way we support usage of Winelib is to require that the app using Wine becomes a Winelib application. I can easily see how this is not acceptable in a lot of instances.
Now our reasoning for doing so is simple: if you use Winelib on i386, you probably want to make use of native DLLs, which means you need to set up the process binary environment appropriately, and hence you need to make your app a Winelib app.
This however places a hard dependency on Wine, and who will accept that? Let's face it, we're not there yet, and even if we were it's still conceptually problematic.
What people really want is to able to simply do: $CC -o myapp -lwine or even better: ... void *wine = dlopen("wine"); if (wine) { ... } This is what we need to provide.
You see, right now we offer the most functionally reach Winelib, but at a high usage point. I can image lots of use cases where people would go for a bit less functionality (say no native DLLs) if they could use Winelib as described above.