Component Object Model - Versionsgeschichte

Schotterebene: Revert - bitte der Belegpflicht nachkommen

2025-03-09T13:28:22Z

Revert - bitte der Belegpflicht nachkommen

← Nächstältere Version		Version vom 9. März 2025, 15:28 Uhr
Zeile 51:		Zeile 51:
	Jede Schnittstelle muss über eine Schnittstellen-Vererbung die Funktionen der hier gezeigten Schnittstelle <code>IUnknown</code> definieren, da dieses die grundlegenden Funktionen für COM implementiert. Eine weitere [[Vererbung (Programmierung)\|Vererbung]] der Schnittstellendefinitionen ist möglich.		Jede Schnittstelle muss über eine Schnittstellen-Vererbung die Funktionen der hier gezeigten Schnittstelle <code>IUnknown</code> definieren, da dieses die grundlegenden Funktionen für COM implementiert. Eine weitere [[Vererbung (Programmierung)\|Vererbung]] der Schnittstellendefinitionen ist möglich.

	Da Programmiersprachen wie [[Visual Basic Script]] keine Typen kennen, hat Microsoft eine weitere Möglichkeit entwickelt, Funktionen aus COM-Schnittstellen aufzurufen. Für diese Möglichkeit muss die Schnittstelle die Funktionen der Schnittstelle <code>IDispatch</code> definieren. Dies ermöglicht es, eine COM-Komponente über <code>IDispatch.Invoke()</code> anzusprechen, ohne dass der COM-Client die [[Typbibliothek]] des Servers kennen muss. Da der Zugriff über das Dispatch-Interface sehr viel langsamer als der Zugriff über ein typisiertes Interface ist, wird oft beides implementiert (''Dual Interface''), so dass bei Programmiersprachen, die [[Zeiger (Informatik)\|Zeiger]] beherrschen ~~oder die Typbibliotheken nutzen können~~, beide Zugriffsmöglichkeiten zur Verfügung stehen.		Da Programmiersprachen wie [[Visual Basic Script]] keine Typen kennen, hat Microsoft eine weitere Möglichkeit entwickelt, Funktionen aus COM-Schnittstellen aufzurufen. Für diese Möglichkeit muss die Schnittstelle die Funktionen der Schnittstelle <code>IDispatch</code> definieren. Dies ermöglicht es, eine COM-Komponente über <code>IDispatch.Invoke()</code> anzusprechen, ohne dass der COM-Client die [[Typbibliothek]] des Servers kennen muss. Da der Zugriff über das Dispatch-Interface sehr viel langsamer als der Zugriff über ein typisiertes Interface ist, wird oft beides implementiert (''Dual Interface''), so dass bei Programmiersprachen, die [[Zeiger (Informatik)\|Zeiger]] beherrschen, beide Zugriffsmöglichkeiten zur Verfügung stehen.

	=== COM-Komponente ===		=== COM-Komponente ===

84.58.70.28: /* COM-Schnittstelle */

2025-03-09T12:17:22Z

COM-Schnittstelle

← Nächstältere Version		Version vom 9. März 2025, 14:17 Uhr
Zeile 51:		Zeile 51:
	Jede Schnittstelle muss über eine Schnittstellen-Vererbung die Funktionen der hier gezeigten Schnittstelle <code>IUnknown</code> definieren, da dieses die grundlegenden Funktionen für COM implementiert. Eine weitere [[Vererbung (Programmierung)\|Vererbung]] der Schnittstellendefinitionen ist möglich.		Jede Schnittstelle muss über eine Schnittstellen-Vererbung die Funktionen der hier gezeigten Schnittstelle <code>IUnknown</code> definieren, da dieses die grundlegenden Funktionen für COM implementiert. Eine weitere [[Vererbung (Programmierung)\|Vererbung]] der Schnittstellendefinitionen ist möglich.

	Da Programmiersprachen wie [[Visual Basic Script]] keine Typen kennen, hat Microsoft eine weitere Möglichkeit entwickelt, Funktionen aus COM-Schnittstellen aufzurufen. Für diese Möglichkeit muss die Schnittstelle die Funktionen der Schnittstelle <code>IDispatch</code> definieren. Dies ermöglicht es, eine COM-Komponente über <code>IDispatch.Invoke()</code> anzusprechen, ohne dass der COM-Client die [[Typbibliothek]] des Servers kennen muss. Da der Zugriff über das Dispatch-Interface sehr viel langsamer als der Zugriff über ein typisiertes Interface ist, wird oft beides implementiert (''Dual Interface''), so dass bei Programmiersprachen, die [[Zeiger (Informatik)\|Zeiger]] beherrschen, beide Zugriffsmöglichkeiten zur Verfügung stehen.		Da Programmiersprachen wie [[Visual Basic Script]] keine Typen kennen, hat Microsoft eine weitere Möglichkeit entwickelt, Funktionen aus COM-Schnittstellen aufzurufen. Für diese Möglichkeit muss die Schnittstelle die Funktionen der Schnittstelle <code>IDispatch</code> definieren. Dies ermöglicht es, eine COM-Komponente über <code>IDispatch.Invoke()</code> anzusprechen, ohne dass der COM-Client die [[Typbibliothek]] des Servers kennen muss. Da der Zugriff über das Dispatch-Interface sehr viel langsamer als der Zugriff über ein typisiertes Interface ist, wird oft beides implementiert (''Dual Interface''), so dass bei Programmiersprachen, die [[Zeiger (Informatik)\|Zeiger]] beherrschen oder die Typbibliotheken nutzen können, beide Zugriffsmöglichkeiten zur Verfügung stehen.

	=== COM-Komponente ===		=== COM-Komponente ===

Schotterebene: Webarchiv statt toter Link

2023-07-01T12:05:34Z

Webarchiv statt toter Link

← Nächstältere Version		Version vom 1. Juli 2023, 14:05 Uhr
Zeile 77:		Zeile 77:
	Jede COM-Komponente wird bei Erzeugung einem Apartment zugeordnet. Falls die Apartment-Anforderungen der erzeugten Komponente zum Apartment des erzeugenden Threads passen, wird das Objekt dem gleichen Apartment zugeordnet. Bei Aufrufen über Prozessgrenzen hinweg liegen die beiden Objekte immer in verschiedenen Apartments. Die Zuordnung zu einem Apartment kann während der Lebensdauer des Objektes nicht geändert werden.		Jede COM-Komponente wird bei Erzeugung einem Apartment zugeordnet. Falls die Apartment-Anforderungen der erzeugten Komponente zum Apartment des erzeugenden Threads passen, wird das Objekt dem gleichen Apartment zugeordnet. Bei Aufrufen über Prozessgrenzen hinweg liegen die beiden Objekte immer in verschiedenen Apartments. Die Zuordnung zu einem Apartment kann während der Lebensdauer des Objektes nicht geändert werden.

	Es gibt drei Arten von Apartments:<ref>[http://www.codeguru.com/Cpp/COM-Tech/activex/apts/article.php/c5529/ Understanding COM Apartments, Part I] ~~(CodeGuru)~~</ref>		Es gibt drei Arten von Apartments:<ref>{{Internetquelle \|url=http://www.codeguru.com/Cpp/COM-Tech/activex/apts/article.php/c5529/ \|titel=Understanding COM Apartments, Part I \|archiv-url=https://archive.md/20120728191235/http://www.codeguru.com/Cpp/COM-Tech/activex/apts/article.php/c5529/ \|abruf=2023-07-01}}</ref>
	* Single Threaded Apartments (STA) besitzen genau einen Thread und beliebig viele Objekte. Es können beliebig viele STAs in einem Prozess existieren. Es erfolgt nur ein Aufruf gleichzeitig an das aufzurufende Objekt. Die restlichen Aufrufe warten in einer Warteschlange auf die Freigabe des Apartment-Threads. Dies impliziert, dass zwei Objekte in demselben STA auch von zwei verschiedenen Clients nicht parallel aufgerufen werden können. Als Besonderheit wird das erste in einem Prozess initialisierte STA automatisch zum Main-STA. Pro Prozess gibt es nur genau ein Main-STA; alle Objekte, die keine explizite Anforderung an das Apartment stellen, werden in diesem erzeugt.		* Single Threaded Apartments (STA) besitzen genau einen Thread und beliebig viele Objekte. Es können beliebig viele STAs in einem Prozess existieren. Es erfolgt nur ein Aufruf gleichzeitig an das aufzurufende Objekt. Die restlichen Aufrufe warten in einer Warteschlange auf die Freigabe des Apartment-Threads. Dies impliziert, dass zwei Objekte in demselben STA auch von zwei verschiedenen Clients nicht parallel aufgerufen werden können. Als Besonderheit wird das erste in einem Prozess initialisierte STA automatisch zum Main-STA. Pro Prozess gibt es nur genau ein Main-STA; alle Objekte, die keine explizite Anforderung an das Apartment stellen, werden in diesem erzeugt.
	* Multi Threaded Apartments (MTA) besitzen beliebig viele Threads. Es gibt in einem Prozess allerdings maximal ein MTA. Dadurch können von mehreren Clients gleichzeitig Aufrufe an das gleiche oder auch verschiedene Objekte erfolgen. Die Anforderungen an die Implementierung der Komponenten sind wegen der notwendigen Threadsicherheit und Reentranz sehr hoch.		* Multi Threaded Apartments (MTA) besitzen beliebig viele Threads. Es gibt in einem Prozess allerdings maximal ein MTA. Dadurch können von mehreren Clients gleichzeitig Aufrufe an das gleiche oder auch verschiedene Objekte erfolgen. Die Anforderungen an die Implementierung der Komponenten sind wegen der notwendigen Threadsicherheit und Reentranz sehr hoch.

Schotterebene: Webarchiv statt toter Link

2023-07-01T12:02:31Z

Webarchiv statt toter Link

← Nächstältere Version		Version vom 1. Juli 2023, 14:02 Uhr
Zeile 60:		Zeile 60:
	Eine COM-Komponente kann mehrere Schnittstellen anbieten. Dies ist in bestimmten Situationen auch notwendig, um ein Programm erweitern zu können, ohne andere Programme neu kompilieren zu müssen, denn der Compiler kodiert die aus der VTable gelesenen Einsprungadressen der vom Client aufgerufenen Funktionen unter bestimmten Umständen fest. Wird die Schnittstelle einer Komponente später geändert, kann sich die Einsprungadresse ändern, was die Funktionstüchtigkeit des Clients beeinträchtigen würde. Zur Erweiterung der Serverfunktionalität wird also stattdessen eine weitere Schnittstelle implementiert.		Eine COM-Komponente kann mehrere Schnittstellen anbieten. Dies ist in bestimmten Situationen auch notwendig, um ein Programm erweitern zu können, ohne andere Programme neu kompilieren zu müssen, denn der Compiler kodiert die aus der VTable gelesenen Einsprungadressen der vom Client aufgerufenen Funktionen unter bestimmten Umständen fest. Wird die Schnittstelle einer Komponente später geändert, kann sich die Einsprungadresse ändern, was die Funktionstüchtigkeit des Clients beeinträchtigen würde. Zur Erweiterung der Serverfunktionalität wird also stattdessen eine weitere Schnittstelle implementiert.

	Eine Vererbung von COM-Komponenten (''Aggregation'') ist durch die Anforderungen der Binärkompatibilität nur in wenigen Programmiersprachen möglich. Dazu wird die zu vererbende Komponente über explizite Durchleitung der Schnittstellen über die erbende Komponente veröffentlicht.<ref>[http://msdn.microsoft.com/de-de/library/xfb1zk2x(VS.80).aspx ~~''Com_Interface_Entry~~ Macros (~~Atl~~)''.] ~~[[MSDN]]~~</ref>		Eine Vererbung von COM-Komponenten (''Aggregation'') ist durch die Anforderungen der Binärkompatibilität nur in wenigen Programmiersprachen möglich. Dazu wird die zu vererbende Komponente über explizite Durchleitung der Schnittstellen über die erbende Komponente veröffentlicht.<ref>{{Internetquelle \|url=http://msdn.microsoft.com/de-de/library/xfb1zk2x(VS.80).aspx \|titel=COM_INTERFACE_ENTRY Macros \|archiv-url=https://archive.md/20130128143928/http://msdn.microsoft.com/de-de/library/xfb1zk2x(VS.80).aspx \|abruf=2023-07-01}}</ref>

	=== COM-Client ===		=== COM-Client ===

Lofote: /* In-process-Server */ ActiveX

2023-03-26T22:19:35Z

In-process-Server: ActiveX

← Nächstältere Version		Version vom 27. März 2023, 00:19 Uhr
Zeile 12:		Zeile 12:
	Im Falle des ''In-process-Servers'' ist die COM-Komponente in einer [[Dynamic Link Library\|DLL]] implementiert (sie tragen unter Windows oft die Dateiendung ''[[OCX]]''). Diese DLLs müssen die Funktionen <code>DllGetClassObject()</code>, <code>DllCanUnloadNow()</code>, <code>DllRegisterServer()</code> und <code>DllUnregisterServer()</code> exportieren.		Im Falle des ''In-process-Servers'' ist die COM-Komponente in einer [[Dynamic Link Library\|DLL]] implementiert (sie tragen unter Windows oft die Dateiendung ''[[OCX]]''). Diese DLLs müssen die Funktionen <code>DllGetClassObject()</code>, <code>DllCanUnloadNow()</code>, <code>DllRegisterServer()</code> und <code>DllUnregisterServer()</code> exportieren.
	Wird eine COM-Komponente eines In-process-Servers erzeugt, so wird der zugehörige Server (ein Server kann mehrere COM-Komponenten anbieten) in den [[Prozess (Informatik)\|Prozess]] des Clients geladen. In-process-Server sind besonders schnell, da der Zugriff auf die Funktionen der COM-Komponenten ohne Umwege erfolgt. Nachteilig ist, dass auf diese Weise jeder Prozess eigenen Speicherplatz mit den benutzten COM-Komponenten belegt und keine gemeinsame Speichernutzung möglich ist.		Wird eine COM-Komponente eines In-process-Servers erzeugt, so wird der zugehörige Server (ein Server kann mehrere COM-Komponenten anbieten) in den [[Prozess (Informatik)\|Prozess]] des Clients geladen. In-process-Server sind besonders schnell, da der Zugriff auf die Funktionen der COM-Komponenten ohne Umwege erfolgt. Nachteilig ist, dass auf diese Weise jeder Prozess eigenen Speicherplatz mit den benutzten COM-Komponenten belegt und keine gemeinsame Speichernutzung möglich ist.
			[[ActiveX]] verwendet dieses Modell.

	==== Local Server ====		==== Local Server ====

Filzstift: BKL-fix, replaced: .NET → .NET (2) mit AWB

2022-05-31T06:20:45Z

BKL-fix, replaced: .NET → .NET (2) mit AWB

← Nächstältere Version		Version vom 31. Mai 2022, 08:20 Uhr
Zeile 72:		Zeile 72:
	Geschieht ein Aufruf im gleichen Apartment zwischen verschiedenen Objekten, ist kein Marshalling erforderlich. Wird jedoch eine Schnittstelle über Apartmentgrenzen hinweg benutzt, muss ein Marshalling erfolgen.		Geschieht ein Aufruf im gleichen Apartment zwischen verschiedenen Objekten, ist kein Marshalling erforderlich. Wird jedoch eine Schnittstelle über Apartmentgrenzen hinweg benutzt, muss ein Marshalling erfolgen.

	Jeder Thread, der COM verwenden möchte, muss sich vor der ersten Verwendung einer COM-Funktionalität einem Apartment zuordnen (MTA) oder ein neues Apartment erstellen (STA). Dies geschieht über die Funktion <code>CoInitialize()</code>. Programmiersprachen mit integrierter COM-Unterstützung (zum Beispiel VB6 und die meisten [[.~~NET~~]]-Sprachen) führen diese Zuordnung oft automatisch durch.		Jeder Thread, der COM verwenden möchte, muss sich vor der ersten Verwendung einer COM-Funktionalität einem Apartment zuordnen (MTA) oder ein neues Apartment erstellen (STA). Dies geschieht über die Funktion <code>CoInitialize()</code>. Programmiersprachen mit integrierter COM-Unterstützung (zum Beispiel VB6 und die meisten [[.Net-Framework]]-Sprachen) führen diese Zuordnung oft automatisch durch.

	Jede COM-Komponente wird bei Erzeugung einem Apartment zugeordnet. Falls die Apartment-Anforderungen der erzeugten Komponente zum Apartment des erzeugenden Threads passen, wird das Objekt dem gleichen Apartment zugeordnet. Bei Aufrufen über Prozessgrenzen hinweg liegen die beiden Objekte immer in verschiedenen Apartments. Die Zuordnung zu einem Apartment kann während der Lebensdauer des Objektes nicht geändert werden.		Jede COM-Komponente wird bei Erzeugung einem Apartment zugeordnet. Falls die Apartment-Anforderungen der erzeugten Komponente zum Apartment des erzeugenden Threads passen, wird das Objekt dem gleichen Apartment zugeordnet. Bei Aufrufen über Prozessgrenzen hinweg liegen die beiden Objekte immer in verschiedenen Apartments. Die Zuordnung zu einem Apartment kann während der Lebensdauer des Objektes nicht geändert werden.
Zeile 90:		Zeile 90:
	* automatisierend		* automatisierend
	zu programmieren.		zu programmieren.
	Viele der Funktionen des „Windows Platform [[Software Development Kit\|SDKs]]“ sind über COM zugänglich. COM ist die Basis, auf der [[Object Linking and Embedding\|OLE-Automation]] und [[ActiveX]] aufbauen. Mit der Einführung des [[.NET]]-Frameworks verfolgte Microsoft allerdings die Strategie, COM unter Windows durch dieses Framework abzulösen. Im Folgenden werden die einzelnen Punkte der Aufzählung genauer erläutert.		Viele der Funktionen des „Windows Platform [[Software Development Kit\|SDKs]]“ sind über COM zugänglich. COM ist die Basis, auf der [[Object Linking and Embedding\|OLE-Automation]] und [[ActiveX]] aufbauen. Mit der Einführung des [[.Net-Framework\|.NET]]-Frameworks verfolgte Microsoft allerdings die Strategie, COM unter Windows durch dieses Framework abzulösen. Im Folgenden werden die einzelnen Punkte der Aufzählung genauer erläutert.

	=== Sprachunabhängigkeit ===		=== Sprachunabhängigkeit ===

Orthographus: Komma

2020-01-11T13:52:32Z

Komma

← Nächstältere Version		Version vom 11. Januar 2020, 15:52 Uhr
Zeile 126:		Zeile 126:

	=== Ortsunabhängigkeit ===		=== Ortsunabhängigkeit ===
	COM ist ''ortsunabhängig'', d. h. dass die einzelnen COM-Komponenten an einer zentralen Stelle ''([[Registrierungsdatenbank]])'' angemeldet werden und so der Zugriff auf die Komponenten unabhängig von ihrem eigentlichen Ort erfolgen kann.		COM ist ''ortsunabhängig'', d. h., dass die einzelnen COM-Komponenten an einer zentralen Stelle ''([[Registrierungsdatenbank]])'' angemeldet werden und so der Zugriff auf die Komponenten unabhängig von ihrem eigentlichen Ort erfolgen kann.

	{{Siehe auch\|Ortstransparenz}}		{{Siehe auch\|Ortstransparenz}}

Invisigoth67: typo

2019-11-28T17:10:53Z

typo

← Nächstältere Version		Version vom 28. November 2019, 19:10 Uhr
Zeile 120:		Zeile 120:

	=== Plattformunabhängigkeit ===		=== Plattformunabhängigkeit ===
	x64-Applikationen können dank Marshalling auf ~~32bittige~~ COM-Server zugreifen (und umgekehrt). Der COM-Server muss dann in einem eigenen Prozess laufen und seine Objekte können demnach nicht als In-process-Server instanziiert werden. COM-Applikationen sind jedoch fast ausschließlich auf die Windows-Betriebssystemfamilie und von dieser unterstützte Hardware angewiesen, eine Plattformunabhängigkeit war konzipiert<ref>{{Internetquelle \|autor=Christian Gross \|url=https://msdn.microsoft.com/en-us/library/aa260790(v=vs.60).aspx \|titel=Building COM Components on UNIX \|hrsg=Microsoft \|datum=1998-07 \|zugriff=2016-05-29 \| sprache=en}}</ref><ref>{{Internetquelle \|autor=Kersten Auel \|url=https://www.heise.de/newsticker/meldung/DCOM-fuer-Unix-jetzt-von-der-Open-Group-11429.html \|titel=DCOM für Unix: jetzt von der Open Group \|hrsg=Heise Medien \|datum=1999-03-08 \|zugriff=2016-05-29}}</ref>, wurde aber wohl nur in wenigen Ausnahmefällen realisiert.		x64-Applikationen können dank Marshalling auf 32-bittige COM-Server zugreifen (und umgekehrt). Der COM-Server muss dann in einem eigenen Prozess laufen und seine Objekte können demnach nicht als In-process-Server instanziiert werden. COM-Applikationen sind jedoch fast ausschließlich auf die Windows-Betriebssystemfamilie und von dieser unterstützte Hardware angewiesen, eine Plattformunabhängigkeit war konzipiert<ref>{{Internetquelle \|autor=Christian Gross \|url=https://msdn.microsoft.com/en-us/library/aa260790(v=vs.60).aspx \|titel=Building COM Components on UNIX \|hrsg=Microsoft \|datum=1998-07 \|zugriff=2016-05-29 \| sprache=en}}</ref><ref>{{Internetquelle \|autor=Kersten Auel \|url=https://www.heise.de/newsticker/meldung/DCOM-fuer-Unix-jetzt-von-der-Open-Group-11429.html \|titel=DCOM für Unix: jetzt von der Open Group \|hrsg=Heise Medien \|datum=1999-03-08 \|zugriff=2016-05-29}}</ref>, wurde aber wohl nur in wenigen Ausnahmefällen realisiert.

	=== Objektorientierung ===		=== Objektorientierung ===

Trustable: Kleinigkeiten verbessert

2019-09-17T10:02:43Z

Kleinigkeiten verbessert

← Nächstältere Version		Version vom 17. September 2019, 12:02 Uhr
Zeile 4:		Zeile 4:

	== Architektur ==		== Architektur ==
	COM basiert auf dem [[Client-Server-Modell]]. Ein COM-Client erzeugt eine COM-Komponente in einem ~~so genannten~~ COM-Server und nutzt die Funktionalität des Objektes über COM-Schnittstellen. Der Zugriff auf Objekte wird innerhalb eines Prozesses durch ~~so genannte~~ COM-Apartments synchronisiert.		COM basiert auf dem [[Client-Server-Modell]]. Ein COM-Client erzeugt eine COM-Komponente in einem sogenannten COM-Server und nutzt die Funktionalität des Objektes über COM-Schnittstellen. Der Zugriff auf Objekte wird innerhalb eines Prozesses durch sogenannte COM-Apartments synchronisiert.

	=== COM-Server ===		=== COM-Server ===
Zeile 26:		Zeile 26:
	Jede Schnittstelle hat eine weltweit eindeutige Identifikationsnummer, die [[Globally Unique Identifier\|GUID]] (''Globally Unique Identifier''). Dadurch können auch mehrere Schnittstellen mit demselben Namen existieren (aber nicht mit derselben GUID).		Jede Schnittstelle hat eine weltweit eindeutige Identifikationsnummer, die [[Globally Unique Identifier\|GUID]] (''Globally Unique Identifier''). Dadurch können auch mehrere Schnittstellen mit demselben Namen existieren (aber nicht mit derselben GUID).

	Um eine programmiersprachenübergreifende Client/Server-Kommunikation zu ermöglichen, findet an der Schnittstelle das ~~so genannte~~ ''[[Marshalling]]'' statt, das die auszutauschenden Daten in eine vordefinierte Binärrepräsentation wandelt.		Um eine programmiersprachenübergreifende Client/Server-Kommunikation zu ermöglichen, findet an der Schnittstelle das sogenannte ''[[Marshalling]]'' statt, das die auszutauschenden Daten in eine vordefinierte Binärrepräsentation wandelt.

	Eine [[Schnittstelle (Objektorientierung)\|Schnittstelle]] erfüllt die Funktion einer [[Abstrakte Klasse\|abstrakten Klasse]], die lediglich virtuelle Elementfunktionen enthält, die (wegen der Trennung von Deklaration und Implementierung) in der [[VTable]] alle auf 0 gesetzt werden. Die C-Version einer Schnittstelle ist entsprechend eine [[Struct\|Struktur]], die [[Funktionszeiger]] enthält. Die erzeugten COM-Objekte nutzt man dabei über [[Zeiger (Informatik)\|Zeiger]] auf deren Schnittstellen.		Eine [[Schnittstelle (Objektorientierung)\|Schnittstelle]] erfüllt die Funktion einer [[Abstrakte Klasse\|abstrakten Klasse]], die lediglich virtuelle Elementfunktionen enthält, die (wegen der Trennung von Deklaration und Implementierung) in der [[VTable]] alle auf 0 gesetzt werden. Die C-Version einer Schnittstelle ist entsprechend eine [[Struct\|Struktur]], die [[Funktionszeiger]] enthält. Die erzeugten COM-Objekte nutzt man dabei über [[Zeiger (Informatik)\|Zeiger]] auf deren Schnittstellen.
Zeile 48:		Zeile 48:
	}		}
	</syntaxhighlight>		</syntaxhighlight>
	Jede Schnittstelle muss über eine Schnittstellen-Vererbung die Funktionen der hier gezeigten Schnittstelle <code>IUnknown</code> definieren, da dieses die grundlegenden Funktionen für COM implementiert. Eine weitere [[Vererbung (~~objektorientierte~~ Programmierung)\|Vererbung]] der Schnittstellendefinitionen ist möglich.		Jede Schnittstelle muss über eine Schnittstellen-Vererbung die Funktionen der hier gezeigten Schnittstelle <code>IUnknown</code> definieren, da dieses die grundlegenden Funktionen für COM implementiert. Eine weitere [[Vererbung (Programmierung)\|Vererbung]] der Schnittstellendefinitionen ist möglich.

	Da Programmiersprachen wie [[Visual Basic Script]] keine Typen kennen, hat Microsoft eine weitere Möglichkeit entwickelt, Funktionen aus COM-Schnittstellen aufzurufen. Für diese Möglichkeit muss die Schnittstelle die Funktionen der Schnittstelle <code>IDispatch</code> definieren. Dies ermöglicht es, eine COM-Komponente über <code>IDispatch.Invoke()</code> anzusprechen, ohne dass der COM-Client die [[Typbibliothek]] des Servers kennen muss. Da der Zugriff über das Dispatch-Interface sehr viel langsamer als der Zugriff über ein typisiertes Interface ist, wird oft beides implementiert (''Dual Interface''), so dass bei Programmiersprachen, die [[Zeiger (Informatik)\|Zeiger]] beherrschen, beide Zugriffsmöglichkeiten zur Verfügung stehen.		Da Programmiersprachen wie [[Visual Basic Script]] keine Typen kennen, hat Microsoft eine weitere Möglichkeit entwickelt, Funktionen aus COM-Schnittstellen aufzurufen. Für diese Möglichkeit muss die Schnittstelle die Funktionen der Schnittstelle <code>IDispatch</code> definieren. Dies ermöglicht es, eine COM-Komponente über <code>IDispatch.Invoke()</code> anzusprechen, ohne dass der COM-Client die [[Typbibliothek]] des Servers kennen muss. Da der Zugriff über das Dispatch-Interface sehr viel langsamer als der Zugriff über ein typisiertes Interface ist, wird oft beides implementiert (''Dual Interface''), so dass bei Programmiersprachen, die [[Zeiger (Informatik)\|Zeiger]] beherrschen, beide Zugriffsmöglichkeiten zur Verfügung stehen.
Zeile 68:		Zeile 68:

	=== Apartments ===		=== Apartments ===
	COM-Objekte werden bei der Erzeugung immer einem ~~so genannten~~ Apartment zugeordnet. Dabei handelt es sich um transparente Rahmen, die zur Synchronisierung von Methodenaufrufen mehrerer Objekte dienen, die mit unterschiedlichen Anforderungen an die [[Threadsicherheit]] arbeiten. Wird COM nicht mitgeteilt, dass eine entsprechende Komponente threadsicher ist, wird COM nur einen Aufruf gleichzeitig an ein Objekt erlauben. Threadsichere Komponenten können auf jedem Objekt beliebig viele Aufrufe gleichzeitig ausführen.		COM-Objekte werden bei der Erzeugung immer einem sogenannten Apartment zugeordnet. Dabei handelt es sich um transparente Rahmen, die zur Synchronisierung von Methodenaufrufen mehrerer Objekte dienen, die mit unterschiedlichen Anforderungen an die [[Threadsicherheit]] arbeiten. Wird COM nicht mitgeteilt, dass eine entsprechende Komponente threadsicher ist, wird COM nur einen Aufruf gleichzeitig an ein Objekt erlauben. Threadsichere Komponenten können auf jedem Objekt beliebig viele Aufrufe gleichzeitig ausführen.

	Geschieht ein Aufruf im gleichen Apartment zwischen verschiedenen Objekten, ist kein Marshalling erforderlich. Wird jedoch eine Schnittstelle über Apartmentgrenzen hinweg benutzt, muss ein Marshalling erfolgen.		Geschieht ein Aufruf im gleichen Apartment zwischen verschiedenen Objekten, ist kein Marshalling erforderlich. Wird jedoch eine Schnittstelle über Apartmentgrenzen hinweg benutzt, muss ein Marshalling erfolgen.
Zeile 93:		Zeile 93:

	=== Sprachunabhängigkeit ===		=== Sprachunabhängigkeit ===
	COM-Komponenten sind unabhängig von der Programmiersprache. COM unterstützt den ~~so genannten~~ [[Binärstandard]]. Die erzeugte Binärdatei stellt einerseits die implementierten Funktionen zur Verfügung und andererseits eine [[Schnittstelle (Objektorientierung)\|Schnittstelle]], die diese Funktionen aufzeigt. Mit Hilfe der Schnittstelle ist es möglich, von anderen Programmen aus die Funktionen zu verwenden. Dabei wird mit Konzepten aus dem Bereich [[Verteiltes System\|Verteilte Systeme]] gearbeitet.		COM-Komponenten sind unabhängig von der Programmiersprache. COM unterstützt den sogenannten [[Binärstandard]]. Die erzeugte Binärdatei stellt einerseits die implementierten Funktionen zur Verfügung und andererseits eine [[Schnittstelle (Objektorientierung)\|Schnittstelle]], die diese Funktionen aufzeigt. Mit Hilfe der Schnittstelle ist es möglich, von anderen Programmen aus die Funktionen zu verwenden. Dabei wird mit Konzepten aus dem Bereich [[Verteiltes System\|Verteilte Systeme]] gearbeitet.

	=== Versionsunabhängigkeit ===		=== Versionsunabhängigkeit ===
Zeile 120:		Zeile 120:

	=== Plattformunabhängigkeit ===		=== Plattformunabhängigkeit ===
	x64-Applikationen können dank Marshalling auf 32bittige COM-Server zugreifen (und umgekehrt). Der COM-Server muss dann in einem eigenen Prozess laufen und seine Objekte können demnach nicht als In-process-Server instanziiert werden. COM-Applikationen sind jedoch fast ausschließlich auf die Windows-Betriebssystemfamilie und von dieser unterstützte Hardware angewiesen, eine Plattformunabhängigkeit war konzipiert<ref>{{Internetquelle \|autor=Christian Gross \|url=https://msdn.microsoft.com/en-us/library/aa260790(v=vs.60).aspx \|titel=Building COM Components on UNIX ~~\|werk=~~ \|hrsg=Microsoft \|datum=1998-07 \|zugriff=2016-05-29 \| sprache=en}}</ref><ref>{{Internetquelle \|autor=Kersten Auel \|url=https://www.heise.de/newsticker/meldung/DCOM-fuer-Unix-jetzt-von-der-Open-Group-11429.html \|titel=DCOM für Unix: jetzt von der Open Group \|hrsg=Heise Medien \|datum=1999-03-08 \|zugriff=2016-05-29}}</ref>, wurde aber wohl nur in wenigen Ausnahmefällen realisiert.		x64-Applikationen können dank Marshalling auf 32bittige COM-Server zugreifen (und umgekehrt). Der COM-Server muss dann in einem eigenen Prozess laufen und seine Objekte können demnach nicht als In-process-Server instanziiert werden. COM-Applikationen sind jedoch fast ausschließlich auf die Windows-Betriebssystemfamilie und von dieser unterstützte Hardware angewiesen, eine Plattformunabhängigkeit war konzipiert<ref>{{Internetquelle \|autor=Christian Gross \|url=https://msdn.microsoft.com/en-us/library/aa260790(v=vs.60).aspx \|titel=Building COM Components on UNIX \|hrsg=Microsoft \|datum=1998-07 \|zugriff=2016-05-29 \| sprache=en}}</ref><ref>{{Internetquelle \|autor=Kersten Auel \|url=https://www.heise.de/newsticker/meldung/DCOM-fuer-Unix-jetzt-von-der-Open-Group-11429.html \|titel=DCOM für Unix: jetzt von der Open Group \|hrsg=Heise Medien \|datum=1999-03-08 \|zugriff=2016-05-29}}</ref>, wurde aber wohl nur in wenigen Ausnahmefällen realisiert.

	=== Objektorientierung ===		=== Objektorientierung ===

Horst Gräbner: Die letzte Textänderung von 2A02:810D:E80:6B54:D9B1:DBCF:D7E4:5F97 wurde verworfen; keine Verbesserung

2018-11-25T18:01:34Z

Die letzte Textänderung von 2A02:810D:E80:6B54:D9B1:DBCF:D7E4:5F97 wurde verworfen; keine Verbesserung

← Nächstältere Version		Version vom 25. November 2018, 20:01 Uhr
Zeile 24:		Zeile 24:
	Die COM-Schnittstelle dient der Kommunikation zwischen Client und Server. Eine COM-Komponente kann dazu über allgemein definierte und vorgegebene Schnittstellen (zum Beispiel IUnknown, IDispatch) sowie über spezielle Schnittstellen angesprochen werden.		Die COM-Schnittstelle dient der Kommunikation zwischen Client und Server. Eine COM-Komponente kann dazu über allgemein definierte und vorgegebene Schnittstellen (zum Beispiel IUnknown, IDispatch) sowie über spezielle Schnittstellen angesprochen werden.

	Jede Schnittstelle hat eine ~~global~~ eindeutige Identifikationsnummer, die [[Globally Unique Identifier\|GUID]] (''Globally Unique Identifier''). Dadurch können auch mehrere Schnittstellen mit demselben Namen existieren (aber nicht mit derselben GUID).		Jede Schnittstelle hat eine weltweit eindeutige Identifikationsnummer, die [[Globally Unique Identifier\|GUID]] (''Globally Unique Identifier''). Dadurch können auch mehrere Schnittstellen mit demselben Namen existieren (aber nicht mit derselben GUID).

	Um eine programmiersprachenübergreifende Client/Server-Kommunikation zu ermöglichen, findet an der Schnittstelle das so genannte ''[[Marshalling]]'' statt, das die auszutauschenden Daten in eine vordefinierte Binärrepräsentation wandelt.		Um eine programmiersprachenübergreifende Client/Server-Kommunikation zu ermöglichen, findet an der Schnittstelle das so genannte ''[[Marshalling]]'' statt, das die auszutauschenden Daten in eine vordefinierte Binärrepräsentation wandelt.