COM oder nicht COM...? (Split aus: Verknüpfungen erstellen)

[Demirug]

Ach so schlimm ist COM nun auch nicht. Und über 95% aller sachen die mit der Shell zu tun haben dürften über COM laufen.

[Exxtreme]

Originally posted by MeLLe
Wenn Du COM net magst, bekommst Du VB-Code :D
Sollte ja auch über C++ nutzbar sein, die Funktion aus der VB-Runtime. Oder?

Danke. Es muss aber C++ sein. Ich programmiere nämlich nicht mit VB.

Ohhh man, warum ausgerechnet COM? Die hätten es auch mit dem Win32-API machen können. Wäre viel einfacher. Ist aber typisch MS.

Gruß
Alex

[Demirug]

Win32-API ist tot. da wird nur noch das nötigste gemacht.

COM liegt aber auch schon im sterben.

[Exxtreme]

Originally posted by Demirug
COM liegt aber auch schon im sterben.
Zum Glück. ;)
Also eine verwirrendere und umständlichere Programmiertechnik ist mir noch nie untergekommen. Ich weiss, .NET wird's richten.
Ich bin aber trotzdem gespannt, wann MS .NET fallen lässt weil es sich mal wieder herausstellt, daß es doch nicht das Wahre ist.
;)

Gruß
Alex

[Demirug]

Originally posted by Exxtreme
Ich bin aber trotzdem gespannt, wann MS .NET fallen lässt weil es sich mal wieder herausstellt, daß es doch nicht das Wahre ist.
;)

Gruß
Alex

Wieso nicht das wahre? Es schlägt alles was ich auf dem Gebiet bisher gesehen habe.

[Exxtreme]

Originally posted by Demirug


Wieso nicht das wahre? Es schlägt alles was ich auf dem Gebiet bisher gesehen habe.
Das waren OLE, ActiveX und COM auch... zumindest laut Micros~1. Warte noch 3-4 Jahre, dann kommt in dieser Richtung wieder was Neues von MS. Wobei ich .NET auch ganz nett ;) finde. Ich befasse mich aber nicht soo stark mit den Programmier- Sprachen und Techniken von Micros~1.

Gruß
Alex

[zeckensack]

OT-Kommentar zu COM:
COM brauchte MS nur deshalb, um die eigenen Programmierinterfaces offenlegen zu können, ohne den eigenen Quellcode herzugeben. Eine andere Daseinsberechtigung außer die Verschleierung von 'Firmengeheimnissen' gibt es dafür nicht.

[Demirug]

Originally posted by zeckensack
OT-Kommentar zu COM:
COM brauchte MS nur deshalb, um die eigenen Programmierinterfaces offenlegen zu können, ohne den eigenen Quellcode herzugeben. Eine andere Daseinsberechtigung außer die Verschleierung von 'Firmengeheimnissen' gibt es dafür nicht.

Du bist sicher das du den Sinn und Zweg von COM wirklich verstanden hast? Denn das was du aufführst geht genausogut mit einer C API im Still der Win32.

[zeckensack]

Originally posted by Demirug


Du bist sicher das du den Sinn und Zweg von COM wirklich verstanden hast? Denn das was du aufführst geht genausogut mit einer C API im Still der Win32. Nein, COM kann selbstredend mehr als eine C-API. Klassen und Objekte halt :)

Nur da ich selbst schonmal versucht habe, echte C++ Klassen in eine LIB zu schmeißen, weiß ich daß man in den Headers soviel mit hineinschreiben muß, daß
1)alle Welt sieht, wie die Klasse funktioniert
2)das erste Update das neue Member-Variablen einführt die Abwärtskompatibilität den Bach runter gehen lässt

In einer freien Welt, wo ich zu jedem Interface gleich den zugrundeliegenden Quellcode kriege, wäre kein Platz und kein Bedarf für COM. So meinte ich das.

[Demirug]

"In einer freien Welt, wo ich zu jedem Interface gleich den zugrundeliegenden Quellcode kriege, wäre kein Platz und kein Bedarf für COM. So meinte ich das."

zeckensack, ich weis das du des Programmieren mächtig bist und auch schon grösser Dingen (Glide-Wrapper) erfolgreich zum Abschluss gebracht hast. Aber dieses Aussage ist nun wirklich nicht haltbar.

Ich habe hier eine Core System das von mehr als einem Programm bei uns genutzt wird. Jeder der Entwickler dieser "Frontends" hat vollständigen Zugriff auf die Quellcodes des Cores. Trotzdem exportiert der Core alle Funktionen über COM nach aussen. Der Grund dafür ist einfach:

1. Von Zeit zu Zeit müssen wir die Funktionalität des Cores erweitern. Dies geschieht dann über neue Interfaces zu den bestehenden Objekten. Programme die diese neuen Sachen nicht brauchen kümmern sich überhaupt nicht darum und laufen ohne das man sie anfassen muss auch mit der neuen DLL.

2. Unser System brauchte eine Plugin Technik. Dank COM bekammen wir die geschenkt. Jedes Pluginmodul unterstützt einfach das entsprechende Interface und das wars. vorallem mussten wir uns nicht um so nervige Sachen wie das Dynamische laden von DLLs kümmern. Und wenn wir jetzt neue Plugins mit erweiterten Möglichkeiten einführen gibt es einfach ein neues Interface dafür und die alten Plugins laufen ohne Änderung weiter.

Also erzähl mir bitte nicht das es kein Bedarf für COM gibt. COM ist zwar nicht perfekt aber es hat für uns eine ganze Menge Probleme gelöst.

[Exxtreme]

Sorry zeckensack aber ich muss mich eher Demirugs Argumentation anschliessen. Auch bei COM-Objekten/Klassen musst du der Welt sagen, wie sie funktionieren sonst weiss niemand was damit anzufangen. Und wie du selbst sagtest, die Abwärtskompatibilität kann flöten gehen, wenn man was in einer "klassischen" Lib was ändert, was bei COM eigentlich nicht sein darf. COM ist IMHO eher ein Versuch, viele Sachen aus anderen Programmen/Libs sprachunabhängig wiederverwertbar zu machen und man kann der geliebten "DLL-Hell" eher ein Schnippchen schlagen. Man kann AFAIK z.B. den Renderer von MS Word in eigene Programme, egal in welcher Programmiersprache einbinden usw.

Leider ist COM doch nicht soo einfach zu verstehen und anzuwenden, speedmässig soll's auch nicht das Wahre sein (Achtung, Gerücht!), und man hat einen ziemlich grossen "Initialisierungsaufwand" bei grösseren Sachen.

Gruß
Alex

[zeckensack]

Hmmm @ Demirug

Alles was ich bisher von COM kannte war quasi eine Übereinkunft darüber, wie die zu exportierenden Klassen deklariert werden.

1)Mittels einer C-Like 'Create' Funktion wird das Interface erzeugt (Funktionszeiger werden in eine struct geschrieben)

2)COM-Objekte müssen den standardisierten Mechanismus zur Abfrage ihrer Methoden haben (pUnkOuter oder so aka das Unknown-Interface)

Daß sich damit auch eigene Arbeiten automatisieren lassen, war mir schlichtweg nicht bekannt, mein Kommentar gründete sich auf die Annahme, daß außer dem oben genannten nichts weiter an COM dran sei.
Da das wohl falsch war, tschuldigung, mein Fehler ;)

@Alex bzgl Performance
Ein COM-Objekt verhält sich ähnlich einer virtuellen Klasse, alle Methodenaufrufe erfolgen also indirekt über Funktionszeiger. Lässt sich IMO heutzutage durchaus verschmerzen :)

[Demirug]

zeckensack,

ok dann war dein Kommentar verständlich. :)

Exxtreme,

der Speed ist wie Zeckensack kein Problem da ein Aufruf nicht länger dauert als ein normaler Win32 Aufruf. Das mit dem Vorbehalten wegen dem Speed kommt daher das es beim COM ein spezieles Interface (IDispatch) gibt das von den alten VB Versionen und noch heute von den Scriptsprachen genutzt wird. Aufrufe über diese Interface sind etwas langsamer als die bei den "normalen" Interfaces.