WineHQ css; binfmt && Mono && wine

[Dimi Paun]

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.


-- 
Dimi Paun <dimi at lattica.com>
Lattica, Inc.