Forum OpenACS Q&A: Attempting to call a win32 dll from ACS running on Linux

Hello all.
I have a Very Happy client whose users are clicking away to their
heart's content on his ACS 3.4.10 system
that we built for him using Oracle on Linux. This client has just
presented us with a problem he would like solved:
he has a proprietary Win32 dll he would like the application to be
able to call. I don't have the source code but
do know the inputs to and outputs from the dll.

I've been considering a few ways of achieving this goal (performance
and cost may or may not be goals here).

I can break this task down to:

Get a Windows or Windows-like OS that will run the dll.

Find a way of running the dll.

Find a way of transporting the output from the dll to the ACS.

3 possible solutions are:

1. get a Windows box, put the dll on it, write a wrapper program to
call it. Put a webserver on the Windows box, get that
to call the wrapper program on a page. Hook that page into one of my
ACS pages using ns_httpget or something. Extra cost
and hassle of supporting a new server.

2. Using something like VMWare or Wine, use my current Linux box and
put the dll on it. Maybe output to some format somewhere
both Win32 and Linux can see? AOLserver can then pick up this output.

3. find some magic piece of software that allows Win32 dlls to be
called from Linux and then use AOLserver's exec command!

Should I be looking at XML-RPC or SOAP?

Tips and pointers greatly appreciated.

A windows machine and a XML-RPC interface to the DLL would probably be the simplest to implement solution (if you don't consider the extra machine to be a complexity).

If you want to do it on the same machine you're on now, then Wine should be able to run it. There are a few Linux programs (mplayer and the Crossover plugin stuff come to mind) calling into win32 DLLs. I wouldn't try to do it from AOLserver's address space though -- just write a second program that loads the DLL using Wine and talks to AOLserver through a socket.

Thanks Petru, that was very helpful. I think the time saved using the XML-RPC solution would probably off-set the cost of the extra machine. I've been researching some XML RPC solutions for ACS, there seems to be quite a choice. Hopefully, there's one available that will work with Classic ACS 3.4.

BTW, are there other alternatives as good as XML? As I'm writing the wrapper for the dll, I have total control of how the data comes back, it can be in any format I choose. Or is the main advantage with using XML to do with the amount of tools available?

The main (only?) advantage of going with XML-RPC is the fact that you already have the client and server libraries for whatever languages you want to use (client on Tcl and C or VB (?) on the server, in your case). You could design a lighter weight protocol specifically for this use, but it would take so much time that it probably doesn't make business sense.

I've been researching some XML RPC solutions for ACS, there seems to be quite a choice. Hopefully, there's one available that will work with Classic ACS 3.4..

I presently use the one that's available here in the SDM (ns_xmlrpc; https://openacs.org/sdm/one-package.tcl?package_id=12) with a OpenACS 3.x vanilla install. Works pretty well. I would imagine it would work with Classic ACS as well; it's not OpenACS specific, I don't think...if it is, it would be trivial to fix.