Hi! I need help determining the feasibility of writing a wrapper around a DLL so that I can call it from a Linux machine, perhaps as a SO. I'm looking for either a member of this list that could contract with us for support, or pointers to a more appropriate place where I can search for such a person. If you're interested in learning more, please read on - otherwise, thanks for your time!
The DLL in question is one that interacts with call recording equipment in a telephone switch. Our customer has an incoming call center where they currently use windows machines on the desktops of the telephone agents. They're looking to replace these desktops with Linux machines, and are trying to convert to a 100% non-Microsoft shop. This DLL has five or six function calls that presumably communicates over the network with the switch.
My initial thought was that we have three choices of how to architect a solution:
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.
I'm looking for someone who has done #3 for other DLLs, and understands the issues that might come up in getting a third party DLL to run under WINE without active support from the DLL's authors. I myself have used Linux quite extensively but have not had the opportunity to use WINE directly, so we will likely need some help in setting up our WINE environment. We've got funding to pursue this, so if you can show me that you've done something like this before, we will pay you to first do a feasibility analysis on the DLL in question, and then implement it.
Thanks!
John
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.
So can this winlib app be made into a winlibapp.so that could be say loaded by a java app or does it actually have to be an executable binary?
Ken.
On Mon, 2003-10-06 at 17:55, Dimitrie O. Paun wrote:
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.
On 8 Oct 2003, Gaul, Ken wrote:
So can this winlib app be made into a winlibapp.so that could be say loaded by a java app or does it actually have to be an executable binary?
It has to be an executable binary.
-
Dimitrie O. Paun -
Gaul, Ken -
John Conneely