What does it take to run a third-party DLL under Wine?

[Dimitrie O. Paun]

On Mon, 6 Oct 2003, John Conneely wrote:

> 1)       Port the code to Linux.  I eliminated this as a choice because
> we don't have the source code for the DLL.
> 2)       Use some kind of RPC mechanism (COBRA, SOAP, etc.) to have the
> DLL running under windows on a server.  This would work in principle,
> and apparently it is the preferred solution by the maker of the DLL.
> However, it violates our client's no-Microsoft-code mandate, and our
> customer has rejected this as a solution.
> 3)       Write a wrapper to use the DLL running under WINE.  This is
> what I am pursuing now.

Currently, you can not call a native (PE) DLL directly from a Linux (ELF)
app -- you can do that esaily from a Winelib app. So you have two choices:
  A) Make your app a Winelib app. If you can do this, you need nothing
     more, you can simply use the .DLL as is. This might not be a big
     deal, it changes a little the way you link the app, and places some
     restrictions on what it can do/link with, but you may be able to
     live with it.
  B) If you want to keep your app a non-Winelib app, you will have to
     go for (2). The advantage is that initially you can test your RPC
     solution against real Windows, and when done, simply replace
     Windows with Wine. It's an incremental approach that leaves your
     choices open in terms of final deployment. The trick here is to
     choose the RPC mechanism carefully so you don't use stuff that is
     not currently implemented/stable in Wine, otherwise you will not
     be able to replace Windows with Wine.

Of course, all this assumes that the DLL does not make use of unimplemented
functionaliy in Wine. If it does, you will need to put more work into fixing
that. If your current Windows app works under Wine as it stands now, then
you are OK.

-- 
Dimi.