tags:

views:

1991

answers:

6

We need to interface to 3rd party app, but company behind the app doesn't disclose message protocol and provides only Windows DLL to interface to.

Our application is Linux-based so I cannot directly communicate with DLL. I couldn't find any existing solution so I'm considering writing socket-based bridge between Linux and Windows, however I'm sure it is not such a unique problem and somebody should have done it before.

Are you aware of any solution that allows to call Windows DDL functions from C app on Linux? It can use Wine or separate Windows PC - doesn't matter.

Many thanks in advance.

+1  A: 

Calling the DLL's functions themselves is of course only the tip of the iceberg. What if the DLL calls Win32, then you'd have a rather massive linking problem. I guess Wine could help you out there, not sure if they provide a solution.

unwind
A: 

I haven't done it, but you might be able to create a wrapper for it using MONO.

GeekyMonkey
A: 

IMO, the best bet is to use Sockets. I have done this previously and it works like a charm.

Aamir
That was my initial idea. It seems that's the way I have to go.
qrdl
+1  A: 

Any solution is going to need a TCP/IP-based "remoting" layer between the DLL which is running in a "windows-like" environment, and your linux app.

You'll need to write a simple PC app to expose the DLL functions, either using a homebrew protocol, or maybe XML-RPC, SOAP or JSON protocols. The RemObjects SDK might help you - but could be overkill.

I'd stick with a 'real' or virtualized PC. If you use Wine, the DLL developers are unlikely to offer any support.

MONO is also unlikely to be any help, because your DLL is probably NOT a .NET assembly.

Roddy
A: 

Sometimes it is better to pick a small vendor over a large vendor because the size of your business will give you more weight for them. We have certainly found this with AV engine vendors.

If you are sufficiently important to them, they should provide either a documented, supported protocol, a Linux build of the library, or the source code to the library.

Otherwise you'll have to run a Windows box in the loop using RPC as others have noted, which is likely to be very inconvenient, especially if the whole of the rest of your infrastructure runs Linux.

Will the vendor support the use of their library within a Windows VM? If performance is not critical, you might be able to do that.

MarkR
A: 

Get a sniffer and learn the protocol. That's what I'm doing.