On Mon, 6 Oct 2003, John Conneely wrote:
Port the code to Linux. I eliminated this as a choice becausewe 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.