Ich beschäftige mich jetzt seit ein paar Tagen mit COM. Ich weiß mittlerweile, was COM ist, wie komm funktioniert (nun ja fast) und wie man mit Delphi einen COM-Server erstellt.

Bleibt nur noch eine Frage, warum müssen COM-Server im System registriert werden?

COM-Server spricht man ja mit deren GUID an.

Die 'Registrierung' ist im Prinzip nichts anderes, als dass in der Registry hinterlegt wird, welche GUID zu welchem COM-Objekt gehört, wo das Binary liegt und noch ein paar Informationen zu Einsprungspunkten in der jeweiligen DLL.

Im Prinzip alles, was das System braucht, um bei einer Anfrage nach dem Objekt dieses auch liefern zu können.

Jo das Problem liegt ja in der Verknüpfung zwischen GUID und Ablageort der DLL oder der EXE.
Man unterscheider mit der Registrierung auch, ob es ein Inproc- oder ein OutprocServer ist. Zudem werden dort der TypMarshaller festgelegt,
der für den Transport der Parameter verantwortlich ist (nur OutProcServer)

Ich habe das jetzt so ausgedrückt:

Zitat:

Ortsunabhängigkeit
COM ist ortsunabhängig, d. h. dass die einzelnen COM-Komponenten an einer zentralen Stelle (Registry) angemeldet werden und so der Zugriff auf die Komponenten unabhängig von ihrem eigentlichen Ort erfolgen kann. Dies bezeichnet man auch als Ortstransparenz\footnote{Ortstransparenz bedeutet in der EDV, dass der Benutzer einer verteilten Anwendung den tatsächlichen Ort des angefragten Objektes oder der angefragten Ressource nicht kennen muss.}. Dies ist auch der Grund, warum COM--Server registriert werden müssen. Da man COM--Server über deren GUID anspricht, muss an einem zentralen Ort hinterlegt werden welche GUID zu welchem COM--Objekt gehört und in welcher DLL sich das COM--Objekt befindet -- deswegen muss ein COM--Client nicht wissen, wo sich die DLL mit dem COM--Server befindet. Dies erledigt alles Windows für ihn. Diese Informationen werden in der Registry hinterlegt. Zusätzlich werden dort Informationen zu dem COM--Server abgelegt, wie zum Beispiel der Einsprungspunkt der DLL, ob es sich um einen in--process Server oder Local Server handelt und es wird der Typmarshaller festgelegt, wenn es sich um einen Local Server handelt.

Ist das soweit richtig und kann man eventuell noch mehr dazu sagen?

Zitat:

COM ist ortsunabhängig, ..

Das kann man sogar soweit führen, dass man COM Objekte aus anderen Windowssystemen über das Netzwerk verwendet.

Zitat:

und es wird der Typmarshaller festgelegt, wenn es sich um einen Local Server handelt.

Ich dachte eigentlich, dass ein Marshall nur für OutOfProcess Server notwendig sind. Weil die Kommunikation über ein externes Protokoll passiert. D.h. Parameterwerte müssen als Bytestream gespeichert und auf der anderen Seite interpretiert werden.
Für InProcessServer ist das nicht notwendig, weil der Aufrufer und COM denselben Speicher sich teilen, ja sogar derselbe Process sind. Es ist also ein ganz normaler Stackwind und Stackunwind Aufruf.

Local Server sind das, was du als out-process Server bezeichnest.

Zitat von Dezipaitor:

Ich dachte eigentlich, dass ein Marshall nur für OutOfProcess Server notwendig sind. Weil die Kommunikation über ein externes Protokoll passiert. D.h. Parameterwerte müssen als Bytestream gespeichert und auf der anderen Seite interpretiert werden.
Für InProcessServer ist das nicht notwendig, weil der Aufrufer und COM denselben Speicher sich teilen, ja sogar derselbe Process sind. Es ist also ein ganz normaler Stackwind und Stackunwind Aufruf.

Man braucht dann einen (eigenen) Marschaller wenn man Datentypen verwendet die der Standard-Marschaller von Windows nicht von sich aus behandeln kann. Bei Visual C++ ist es üblich eigenen eigenen Marschaller zu basteln, bei Delphi kann man AFAIK keinen eigenen entwickeln (außer mit sehr Low-Level API-Aufrufen).

Zitat von Bernhard Geyer:

Man braucht dann einen (eigenen) Marschaller wenn man Datentypen verwendet die der Standard-Marschaller von Windows nicht von sich aus behandeln kann. Bei Visual C++ ist es üblich eigenen eigenen Marschaller zu basteln, bei Delphi kann man AFAIK keinen eigenen entwickeln (außer mit sehr Low-Level API-Aufrufen).

Das schreit ja schon danach, dass jemand eine Kompo dafür entwickelt, oder nicht?

Zitat von Dezipaitor:

Das schreit ja schon danach, dass jemand eine Kompo dafür entwickelt, oder nicht?

Schreien halte ich für übertrieben, da man mit den Standard-Marshaller schon sehr weit kommt. Und in Zeiten von WDSL und SOAP sowie anderen guten reinen Delphi-Mitteltier Lösungen ist denke ich der Markt nicht sehr groß. Und nach MS ist ja COM auf dem Absteigenden Ast. Unter Vista sind ja alle neuen API reine C-Kompatiblen DLL-Schnittstellen.

Im Zweifelsfall streamt (serialisiert) man seine Klassen in einen Memorystream, bupselt den in ein Variant (Array Of Byte) und bläst ihn über das Netz. Auf der anderen Seite wieder in einen Stream und dann auspacken.