What does it take to run a third-party DLL under Wine?
Dimitrie O. Paun
dimi at intelliware.ca
Mon Oct 6 11:55:20 CDT 2003
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.
More information about the wine-devel