Win32::OLE only works on Win32, as OLE is one of the core services provided by the Windows API. Without understanding the differences involved here, you don't have much hope of succeeding in any way here.

What you could do is to emulate the RPC calls of Win32/NT, from what I remember, this is pretty standard RPC, and use DCOM to automate the Win32 Applications from a second machine. But DCOM is only COM and not completely OLE, so you're setting yourself up for lots of pain here. A second solution would be to install Perl on the Win32 machine and just use that. Not much pain involved here. You also could use the Openoffice.org automation, but their document model is horribly broken and really ugly to use.

Thanks.

If we put OLE and ActiveState on an XP box, but the 'brains' and driving logic had to live on the linux side, what communication protocol would you recommend for the 'nix machine to ask the XP machine to do OLE actions and pass data back and forth?

We would be seeking a protocol that is (1) friendly for a developer team that has never done this before, (2) relatively easy to set up, (3) robust, and (4) NOT handrolled.

Any such thing exist?

Thank you very much.

Don't do a tightly coupled system. Pass RTF files, CSV files or whatever from the Linux side to the Win32 side, and have a Perl program monitor the drop directory. Then import the data into Office, munge it and spit it out again.

Another (bad) idea would be to push over actual Perl code to be executed instead of data files, but if you already look in that direction, consider a database to handle outstanding jobs etc. You will have to have Perl code on the Win32 machine in any way, and I would try to avoid any fancy RPC scheme in favour of file based transfer or DB based transfer, where the advantages and disadvantages of both are to be weighed.

You obviously haven't done much research in the direction, so here are some dire warnings:

1. Office is single user. If you have more than one process trying to automate things, you are asking for much trouble.
2. You might be well better off to use SpreadSheet::WriteExcel or simply distributing .pdf files or csv files instead of trying to produce them via OLE.

Give SOAP/XMLRPC a chance. It is very easy to handle - if you dont mind about performace. Check: http://soaplite.com/features.html In one of my former project I used xmlrpc - If you have fixed IPs and no transaction handling it is really one of the easiest 'middlewares' i ever used.

Win32::OLE is extremely tightly coupled to Windows. Essentially the C code in the OLE XS simply provides you access to the native Win32 OLE API. For example one of the first includes is #include <windows.h> ;-)

What is it you want to do? If the (guess) task is to read/write to an Access database or similar they may be other options.

Sadly we need native Windows actions on native Windows objects and files -- we wish it were just Access (and could sue DBI) or Excel (and use Spreadsheet::WriteExcle). Sadly it is more full-blown and windows painful.

Thank you very much.

As another thought, you could try from another side: is there exist any other Linux software that will perform OLE actions from Linux? You could tie it with Perl et voila...

As a third thought, you could write Perl(win32) layer so it will communicate with Linux Perl and perform Win32::OLE commands by any given protocol (start with simple "eval" then grow to some kind of RPC or XML or something)

Forget about win4lin ... I tried to write an Perl/Tk app, which worked under win32 as well as linux. So I gave win4Lin a chance (to emulate win98 under linux) - I had to 'reboot' win98 all the time ... I think it is supposed to work win word or excel quite all right but my experience with ole and tk is not too good.

I hope you'll succeed this way, otherwise go and seek another wisdom here :)

use SOAP::Transport::HTTP;
my $server = SOAP::Transport::HTTP::Daemon
->new(LocalAddr => '192.168.0.1', LocalPort => 666)
->objects_by_reference('MyMod')
->dispatch_with(
  {'http://192.168.0.1/MyMod' => 'MyMod'},
);
$server->handle;
[download]

use SOAP::Lite
# trace => [ all, -transport ],
  dispatch_from => 'MyMod',
  uri => 'http://192.168.0.1/MyMod',
  proxy => ['http://192.168.0.1:666', timeout => 6000]
;
[download]

However, disadvantage of that method is that you have whole another emulated machine (which might be on Linux and chrooted, but still a emulated Windows machine). On the bright side, you don't have to have another windows or fight with system administrators about installing that non-standard perl on Windows boxes.