COM mit MinGW

CStern schrieb:

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.

hustbaer

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

hustbaer schrieb:

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

du doch auch...

CStern

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.

Ben04

dooooomi schrieb:

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

CStern schrieb:

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.

peterchen

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.

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

hustbaer

peterchen schrieb:

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...

peterchen

ja, MIDL generiert nur die "einfachen" Header, so, wie die binäre Schnittstelle definiert ist. Die schönen #import - Wrapper bekommt man da nicht. Aber wenn er die noch nicht kennt, tut das vielleicht nicht.... hm, nee, hast recht, do⁵mi will ja den Rest auch noch mit übersdetzen Ich hatte mich ganz auf das IDL selbst gestürzt.

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.

dooooomi

Danke euch allen (die etwas zum Thema beizutragen hatten ;)).

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...