ich möchte gerne ein Programm, daß offensichtlich für Visual-Studio geschrieben wurde, mit gcc (MinGW) übersetzen. Der Haken dabei ist, daß mittels COM auf einige Funktionen eines anderen Programms zugegriffen wird. Inmitten der #includes steht in etwa folgendes:

#import "foo.exe" no_namespace named_guids

Wie zu erwarten kann mein Compiler damit nicht viel anfangen. Daher meine Frage: Wie kriege ich das mit MinGW ans Laufen? Wieviel Aufwand wäre es, dieses #import Statement durch "richtigen" C++-Code zu ersetzen? Und vor allem, wo finde ich weitere Informationen darüber, wie man sowas macht?

Danke schonmal im Voraus für eure Hilfe.

Du kannst versuchen ob MinGW mit den generierten Include-Files was anfangen kann (keine Ahnung ob da irgendwelche MS-spezifischen Sachen vorkommen).

Die Include-Files kannst du dir entweder von jmd. generieren lassen, oder selbst die Express Edition (ich hoffe die Express Edition kann #import *g*) von Visual Studio runterladen. Dann übersetzt du einfach 1x ein File wo die entsprechende "#import" Zeile drinnensteht, und kopierst dir das generierte File (liegt IIRC dort wo auch die ganzen .obj Files liegen).

Andere Vorschäge...?

Ich würde mal im Netz suchen ob es nicht irgendwelche Tools gibt, die dir Standard-Konforme (oder wenigstens "MinGW-taugliche") Headers aus einer Type-Library erstellen können.

Mit MIDL kannst Du daraus C/C++ import-Header generieren. Die sind zwar nicht ganz so komfortionös wie die #import-generierten, aber auch ok.

Der OLE Viewer (Visual Studio Tools) enthält einen TypeLib-Viewer (die drei komischen Pfeile im Toolbar), damit kannst du foo.exe öffnen und den zugehörigen .IDL - Quelltext angucken.

Mit MIDL kannst Du daraus C/C++ import-Header generieren. Die sind zwar nicht ganz so komfortionös wie die #import-generierten, aber auch ok.

Das klingt schonmal vielversprechend, danke! Inwieweit müßte ich denn den Code des Programms anpassen, wenn ich die mit MIDL generierten Header verwende?

Diese ganze COM-Geschichte ist für mich neu (habe 10 Jahre nicht mehr für Windows programmiert...), und so ganz durchschaue ich die Zusammenhänge noch nicht. Von daher fällt es mir vor allem schwer abzuschätzen, ob es den Aufwand überhaupt wert ist, oder ob ich nicht vielleicht doch besser in den sauren Apfel beiße, und mir Visual Studio besorge...

[...oder ob ich nicht vielleicht doch besser in den sauren Apfel beiße, und mir Visual Studio besorge...

ist doch kostenlos

CStern schrieb:

Wahr ist: Du hast noch nie für Windows programmiert.
Sonst würdest Du wissen, dass COM sehr viel älter ist als 10 Jahre.

was für ein schlaumeier

dooooomi schrieb:

[...oder ob ich nicht vielleicht doch besser in den sauren Apfel beiße, und mir Visual Studio besorge...

ist doch kostenlos

Das ist keine Frage des Preises.

CStern schrieb:

Wahr ist: Du hast noch nie für Windows programmiert.
Sonst würdest Du wissen, dass COM sehr viel älter ist als 10 Jahre.

Hat ja keiner was anderes behauptet. Aber ich erinnere mich noch an eine Zeit, als COM noch nicht so allgegenwärtig war wie heute.

Und noch eine Frage: Wäre es denkbar, mit Visual Studio eine statische Bibliothek zu bauen, die sich um die COM-Sachen kümmert, und dann ein MinGW-Projekt mit dieser Bibliothek zu linken?

Wahr ist: Du hast noch nie für Windows programmiert.
Sonst würdest Du wissen, dass COM sehr viel älter ist als 10 Jahre.

was für ein schlaumeier [/quote]

Gell Deswegen weiß ich auch, dass das kostenlose Zeugs Bullshit ist.

Gell Deswegen weiß ich auch, dass das kostenlose Zeugs Bullshit ist.

du meinst also, das z.b. Microsoft Visual C++ 2008 Express Edition bullshit ist, hmm... achso.

Also ihr seid schon alle ein wenig plem in der Birne ...

du doch auch...

Also ihr seid schon alle ein wenig plem in der Birne ...

Genau. Vielleicht besoffen von diesem .NET-Bullshit.

Oder vielleicht ganz nüchtern: Interessiert mich nicht. Jedem das seine. Der Eine liebt die Kacke der andere eben nicht.

Und noch eine Frage: Wäre es denkbar, mit Visual Studio eine statische Bibliothek zu bauen, die sich um die COM-Sachen kümmert, und dann ein MinGW-Projekt mit dieser Bibliothek zu linken?

Statisch wird problematisch wegen der Unterschiedlichen Objektformaten. Eine DLL geht solange das Interface C oder WinAPI-artig ist. Wie groß ist die COM-Klasse denn? Eventuell kannst du die in VC mit einem C Interface wrappen, dieses in einer DLL exportieren und dann in deiner MinGW-Anwendung importieren und wieder mit einer COM-ähnlichen Klasse wrappen. Ist sehr unschön, aber es geht. Also so in etwa:

VC Teil:

// keine Ahnung ob das jetzt eine korrekte COM Klasse ist
interface IFoo{
public:
  virtual void bar()=0;
  virtual void dispose()=0;
};

IFoo*CreateFoo();

// WinAPI-style Wrapper
extern "C" __stdcall __declspec(dllexport)
void bar(void*f){
  ((IFoo*)f)->bar();
}

extern "C" __stdcall __declspec(dllexport)
void*create(){
  return CreateFoo();
}

extern "C" __stdcall __declspec(dllexport)
void dispose(void*f){
  ((IFoo*)f)->bar();
}

MinGW Teil:

namespace IFooCInterface{
// WinAPI-style Wrapper
extern "C" __stdcall __declspec(dllimport)
void IFoo_bar(void*f);

extern "C" __stdcall __declspec(dllimport)
void*create();

extern "C" __stdcall __declspec(dllimport)
void dispose(void*f);
}

// Wrapper um es wie ein COM aussehen zu lassen
class IFoo{
private:
  void*f;
public:
  void bar(){
    IFooCInterface::bar(f);
  }

  void Dispose(){
    // Wenn deine Anwendung das Referenzzählen benutzt muss das natüRlich anders aussehen
    IFooCInterface::dispose(f);
    delete this;
  }

  friend 
  IFoo*CreateFoo(){
    IFoo* f = new IFoo;
    f->f = IFooCInterface::create();
    return f;
  }
};

Ist aber schon übelstes Gefrickel.

hustbaer schrieb:

Also ihr seid schon alle ein wenig plem in der Birne ...

Genau. Vielleicht besoffen von diesem .NET-Bullshit.

Oder vielleicht ganz nüchtern: Interessiert mich nicht. Jedem das seine. Der Eine liebt die Kacke der andere eben nicht.

Hm.
Also ich bin nicht der der hier noch kein einziges sinnvolles und/oder hilfreiches Kommentar geschrieben hat.

Statische Bibliothek kann gehen, muß nicht - und die möglichen Fehler können recht eklig werden.

Das klingt schonmal vielversprechend, danke! Inwieweit müßte ich denn den Code des Programms anpassen, wenn ich die mit MIDL generierten Header verwende?

Im besten Fall gar nicht, die MIDL generierten Header fordern nur windows.h. Ich hab' aber keine Erfahrung mit MinGW, ob es da noch andere Überraschungen gibt.

COM - Programmierung - insebsondere in C++ - ist von Haus aus nicht so ganz schnucklig, aber ertäglich. Probier's einfach

Wäre auch ziemlich blödsinnig, um ein COM DLL nochmal ein Win32 DLL drumrumzulegen

Statische Bibliothek kann gehen, muß nicht - und die möglichen Fehler können recht eklig werden.

Das klingt schonmal vielversprechend, danke! Inwieweit müßte ich denn den Code des Programms anpassen, wenn ich die mit MIDL generierten Header verwende?

Im besten Fall gar nicht, die MIDL generierten Header fordern nur windows.h. Ich hab' aber keine Erfahrung mit MinGW, ob es da noch andere Überraschungen gibt.

Das Problem wird eher nicht sein dass die MIDL generierten Headers noch irgendwas brauchen, sondern dass sie sich anders Verhalten bzw. gewisse Dinge nicht in der Form anbieten werden wie die von #import generierten.

Mit den von #import generierten kann man z.B. schreiben

long l = comInterface->SomeProperty;
long l2 = comInterface->Items["sepp"]->Value;
comInterface->SomeOperation(); // und wenns schief geht fliegt ein _com_error statt dass ein HRESULT zurückgegeben wird

Ich vermute die MIDL generierten Headers werden diese Funktionen nicht anbieten. z.B. schonmal deswegen weil _com_error eine der "Compiler COM Support Classes" ist. Also Visual Studio spezifisch.

COM - Programmierung - insebsondere in C++ - ist von Haus aus nicht so ganz schnucklig, aber ertäglich. Probier's einfach

Client-Seitig ist es mit #import eigentlich ziemlich schnuckelig. Wäre natürlich cool wenn es ein Tool gäbe welches vergleichbare Headers für mehrere Compiler erstellen könnte...

Da er mit COM nicht so viel Erfahrung hat, ist das hinpfriemeln der Aufrufe auch eher fragwürdig. Würde unter diesen Umständen doch zu VC Express raten.

Alternativ: Die #import-Header generieren lassen, _com_issue_error sowie _bstr_t _variant_t ... ahem... "nachempfinden". Ist aber auch nciht so einfach.

Ich werde die MIDL-Variante in den nächsten Tagen mal ausprobieren, und sehen wie weit ich damit komme. Die Menge an COM-Code die ich brauche ist zum Glück recht überschaubar, so daß ich da eigentlich ganz optimistisch bin. Vorausgesetzt natürlich, daß mir Microsoft oder sonstwer keine weiteren Steine mehr in den Weg legt...