Using Component Object Model (COM) on non-Microsoft platforms

Question

I'm regularly running into similar situations : I have a bunch of COM .DLLs (no IDL files) which I need to use and invoke to be able to access some foreign (non-open, non-documented) data format.

Microsoft's Visual Studio platform has very nice capabilities to import such COM DLLs and use them in my project (Visual C++'s #import directive, or picking and adding them using Visual Basic .NET's dialogs) - and that's the vendors recommended way to use them.

I would be interested into finding a way to use those DLLs on non-microsoft development platforms. Namely, using these COM classes in C++ project compiled with MinGW or Cygwin, or even Wine's GCC port to linux (compiles C++ targeting Win32 into binary running natively on Linux).

I have got some limited success using this driver, but this isn't successful in 100% of situations (I can't use COM objects returned by some methods).

Has someone had success in similar situations ?

Answer 1

I think you should be able to use the free tool Ole/Com Object Viewer to make the header files.

Answer 2

The problem with the Ole/Com Object Viewer packaged with Visual Studio and Windows SDKs is that it produces a broken .IDL out of the .DLL, which can't further be compiled by MIDL into a .H/.CPP pair.

Wine's own reimplementation of OleViewer is currently unstable and crashes when trying to use those libraries.

Answer 3

Answering myself but I managed to find the perfect library for OLE/COM calling in non-Microsoft compilers : disphelper.

(it's available from sourceforge.net under a permissive BSD license).

It works both in C and C++ (and thus any other language with C bindings as well). It uses a printf/scanf-like format string syntax.
(You pass whatever you want as long as you specify it in the format string, unlike XYDispDriver which requires the arguments to exactly match whatever is specified in the type library).

I modified it a little bit to get it also compile under Linux with WineGCC (to produce native Linux elf out of Win32 code), and to handle "by ref" calls automatically (stock disthelper requires the programmer to setup his/her own VARIANT). I'll publish my patches back, as soon as I get NDA clearance (was done on company time).

Answer 4

I have made a tutorial about this once.

See here: http://aimbots.net/tutorials/15301-calling-vb-dll-c-c-executable.html

if you don't mind the purpose.