Diskussion:Component Object Model
Der Link in den Quellen zum T-online Artikel hat quasi NULL Relevanz. Billiges Linkbuilding... (nicht signierter Beitrag von 188.103.236.55 (Diskussion) 10:18, 2. Feb. 2013 (CET))
Der Begriff Apartments wird häufiger benutzt aber nie erklärt oder verlinkt. Was ist denn so ein COM-Apartment? 193.99.160.10
Hallo, was ist mit den seriellen COM1 und COM2-Schnittstellen am Rechner? Gehört wahrscheinlich in einen saparaten Artikel, ein Hinweis darauf würde hier aber nicht schaden. Grüße Nick B.
- Ist erledigt. --Echoray 08:38, 30. Aug 2003 (CEST)
der eintrag "http://de.wikipedia.org/wiki/COM" enthält nur ein re.direct zu diesem artikel
ich denke es währe besser wenn das zu einem 'welches com meinst du denn?'.artikel werden würde wo auf die top.level.domain, die datei.namens.erweiterung mancher dos.programme, die serielle schnitt.stelle und diesem "Component Object Model".artikel --marti7D3 21:06, 15. Jan 2004 (CET)
- Als Originalautor des Artikels habe ich mir einfach mal erlaubt, das so zu machen. 62.178.238.230 13:35, 23. Mär 2004 (CET)
Einige Dinge in diesem Artikel würde ich so nicht stehenlassen, bspw:
- "Architektur": Ein COM-Server bietet COM-Komponenten an die ihrerseits Interfaces anbieten. Ein COM-Objekt ist eine Instanziierung einer COM-Komponente die von einem oder mehreren Interfaces repräsentiert wird. Mit Klassen hat das wenig zu tun, wenngleich COM-Komponenten meist als Klassen implementiert werden. Trotzdem kann eine COM-Komponente auch ohne Objektorientierung geschrieben werden.
- "In-process-Server": Die Endung .ocx steht für Ole Control eXtensions und wird nicht für jeden beliebigen COM-Server verwendet.
- "Objektorientierung": "Beim Einsatz von COM wird objektorientiert gearbeitet." ist zwar oft so, wird aber von COM nicht vorausgesetzt. COM Komponenten können sowohl von nicht-objektorientierten Sprachen erstellt als auch genutzt werden. Einfaches Beispiel: Assembler.
- "Versionsunabhängigkeit": Das Hinzufügen neuer Interfaces zu einem bestehenden Interface als "die von Microsoft angedachte Form, Softwarekomponenten zu erweitern, da so keine Inkonsistenzen entstehen" ist so nicht vollständig korrekt, da dies nur eine (nicht die Beste) Möglichkeit für Komponentenupdates ist. Unter bestimmten Voraussetzungen muss bspw. sogar eine neue Komponente mit neuer GUID erstellt werden, welche ggf. die alte Komponente nutzt.
- "Sprachunabhängigkeit": Es muss keine "objektorientierte Sprache" verwendet werden. Der von objektorientierten Sprachen generierte Binärcode wird zwar mit geeigneten Compilern gerne dafür verwendet, es kann aber auch jede andere Sprache benutzt werden. Es wäre kein binärer Standard, wenn Objektorientierung benötigt würde. Auch hier Beispiel Assembler. Übrigens ist es soetwas wie ein "glücklicher Zufall" dass das von MS Compilern verwendete v-table layout kompatibel zu den Anforderungen von COM ist; das ist bei anderen Compilern oft nicht so!
- "COM-Interface": Die IDL wird nicht benötigt, um eine COM-Komponente bereitzustellen; das geht auch ohne, bspw. bei inproc-servern wenn die Funktionen bekannt sind.
und vieles mehr. Ich empfehle das Buch "Inside COM" von Dale Rogerson (MS-Press) in dem deutlich wird, dass COM viel basaler und damit auch viel flexibler ist als hier angedeutet.
Grüße Oliver
- Ändere den Artikel doch entsprechend. --Ben g 00:14, 18. Jan 2006 (CET)
Eine Frage: beim studieren von Literatur und auch auf den Microsoft-Seiten wird immer gesagt, dass COM Objekte sowohl in DLLs als auch in Executables gepackt werden können. Das wird im Artikel nicht erwähnt. Da ich da aber nicht sicher bin, will ich´s auch nicht einfach ´rein schreiben. Gruss Torsten 06.04.2006
- Das steht eigentlich ziemlich eindeutig im Abschnitt COM-Server. Ben g 01:31, 8. Apr 2006 (CEST)
Hallo, ich habe mal den COM Artikel etwas aufpoliert. Mag sein, dass er nocht nicht etwas mehr Schliff braucht. Ist, aber ich denke es ist besser als vorher, allerdings auch kein leichtes Thema. Häger 30.01.2007
Hab auch versucht, noch etwas mehr Genauigkeit einzubringen und auch das Thema Objektorientierung zu präzisieren.
Es gibt nicht nur 3 Apartmentmodelle sondern 4 (oder 3 1/2):
* main STA: wenn bei der Registrierung kein Apartmenttyp angegeben wird, geht Windows davon aus, daß die Komponente nicht threadsicher ist und läßt sie im main STA laufen. * STA * MTA * TNA
Der main STA ist der Thread des Prozesses, der zuerst CoInitialize aufgerufen hat (siehe [Microsoft]). Er ist eine besondere Form des STAs, und kann daher zwar als selbes Apartmentmodel angesehen werden, er bleibt dennoch ein "besonderes" Apartment. Der main STA wird vor allem für ActiveX verwendet, da ActiveX Controls kein Apartement bei der Registrierung angeben, da threadsicheres Programmieren für ActiveX Controls nicht vorgeschrieben ist. Insofern würde ich den main STA am Rande erwähnen.
siehe hierzu auch "Transactional COM+: Building Scalable Applications, Tim Ewald, Addison-Wesley"
Die Anzahl der STAs ist nicht unendlich, wie im Artikel suggeriert wird; es gibt eine Formel um auszurechnen wie viele STAs pro Prozess zur Verfügung stehen können (ebenfalls in "Transactional COM+" nachzulesen); das hängt u.a. von der Anzahl der CPUs und an ein/zwei Registryeinstellungen ab. Woher diese Formel stammt steht dort (im Buch) leider nicht, hierfür währen weitere Nachforschungen notwendig. Ich vermute die Formel findet sich in der COM Spec von Microsoft.
--Drseek 14:36, 4. Nov. 2008 (CET)drseek
Interfaces: struct oder class?[Quelltext bearbeiten]
Hi Ben,
ich hatte damals den Abschnitt verfasst und dann, als ich gesehen habe, dass es faktisch falsch ist (ein Interface ist in seiner C++-Repräsentation eben nicht unbedingt eine abstrakte Klasse) das "bzw. eine Struktur" hinzugefügt. Bitte überleg nochmal, ob das um der Richtigkeit willen nicht besser drin bleiben sollte.
-- 85.70.197.210 20:09, 12. Okt. 2010 (CEST)
- Die Formulierung "in seiner C++-Repräsentation" ist vielleicht missverständlich, und auch nicht von mir, aber es geht in diesem Abschnitt eben nicht um MIDL-Code. --ben g 03:26, 13. Okt. 2010 (CEST)
- Die Formulierung (der Absatz) ist von mir. Die jetzige Formulierung ist in Ordnung, damit bin ich einverstanden. -- 85.70.197.210 09:24, 13. Okt. 2010 (CEST)
Lebensdauer[Quelltext bearbeiten]
Der Abschnitt "Lebensdauer" in "COM-Komponente" enthielt eine meiner Meinung nach ungenaue Formulierung: AddRef() und Release() werden nicht nur bei Instanziierung und Freigabe einer Instanz benutzt, sondern immer dann, wenn die Instanz irgendwo verwendet wird. Release() zerstört nicht automatisch das Object, und AddRef() erzeugt es nicht. Die Zerstörung hängt, wie der Abschnitt richtig sagt, von einem Referenzzähler ab. Hoffe, so passt es besser. --IUnknown68 (Diskussion) 19:14, 30. Okt. 2012 (CET)
COM-Schnittstelle[Quelltext bearbeiten]
Im Abschnitt "COM-Schnittstelle" heißt es über die beiden Zugriffsmöglichkeiten "IUnknown" und "IDispatch": "... so dass bei Programmiersprachen, die Zeiger beherrschen, beide Zugriffsmöglichkeiten zur Verfügung stehen". Das kann nicht richtig sein, da die Sprache "Visual Basic" (gemeint ist nicht die moderne .NET-Version) beide Möglichkeiten nutzen kann, jedoch keine Zeiger unterstützt. (nicht signierter Beitrag von 80.157.182.27 (Diskussion) 13:06, 26. Mär. 2015 (CET))
Sicherheit[Quelltext bearbeiten]
Ich habe den Artikel nur flüchtig überflogen, aber keine relevanten Informationen betreffend Sicherheit gefunden. Soweit ich verstanden habe ist DCOM eine extern steuerbare Anwendung und nicht deaktivierbar ausser im bios mit selben Eigenschaften wie remote nur unter anderen voraussetzungen.
Wäre ja ein irre Risiko ausser ich hab so manches total falsch verstanden. Also bitte fals möglich sicherheits relevante schwächen anfügen.
Danke
Jo