Component Object Model: differenze tra le versioni

Versione delle 13:54, 16 nov 2010

Versione attuale delle 14:45, 21 nov 2020

(55 versioni intermedie di 29 utenti non mostrate)

Riga 1:

IlIn [[informatica]] il '''Component Object Model''' (noto con l'[[acronimo]] '''COM''', [[Lingua inglese|inglese]] per ''Modello ada oggetti per componenti'') è un'[[interfaccia (programmazione)|interfaccia]] per componenti [[software]] introdotta da [[Microsoft]] nel [[1993]]. COM permette la [[comunicazione tra processi]] e creazione dinamica di oggetti con qualsiasi [[linguaggio di programmazione]] che supporta questa tecnologia.<ref>{{cita web|url=https://www.microsoft.com/com/|titolo=Component Object Model Technologies|editore=Microsoft Corporation}}</ref> Il termine COM è spesso usato nel mondo dello sviluppo software con più significati: [[Object Linking and Embedding|OLE]], [[OLE Automation]], [[ActiveX]], COM+ e [[Distributed Component Object Model|DCOM]]. Nonostante l'introduzione di COM risalga al 1993, Microsoft ha iniziato ad utilizzare con enfasi questo nome solamente nel [[1997]].

Sebbene sia stato [[Portabilità|portato]] anche su altre piattaforme, COM è utilizzato principalmente con [[Microsoft Windows]]. Si prevede una progressiva sostituzione almeno parziale di COM da parte del [[framework]] [[Microsoft .NET]].

==Storia==

[[Anthony Williams]], una delle principali menti coinvolte nella creazione dell'architettura COM, distribuì un paio di documenti Microsoft interni che trattavano il concetto di componenti software; "''Object architecture: dealing with the unknown - or - Type safety in a dynamically extensible class''" ("''Architettura di un oggetto: trattare l'ignoto - o - Sicurezza dei tipi in una classe dinamicamente estensibile''") nel [[1988]] e "''On inheritance: what it means and how to use it''" ("''Sull'ereditarietà: cosa significa e come si usa''") nel [[1990]]. Questi gettarono le basi per molte, se non tutte, delle idee dietro ai fondamenti di COM.

Da molte di quelle idee nacque il primo [[framework]] ad oggetti di Microsoft, [[Object Linking and Embedding|OLE]] ([[acronimo]] dell'[[Lingua inglese|inglese]] ''Object linking and embedding'', sta per ''Collegamento ed incorporazione di oggetti''). OLE fu costruito partendo dal [[Dynamic Data Exchange|DDE]] e progettato con un occhio di riguardo per i [[Documento composito|documenti compositi]]; fu introdotto per la prima volta con [[Microsoft Word|Word per Windows]] ed [[Microsoft Excel|Excel]] nel [[1991]], e fu successivamente incluso in Windows, a partire dalla versione [[Windows 3.x|3.1]] del [[1992]].

Riga 11:

Nel 1991 Microsoft introdusse la tecnologia [[Visual Basic Extension|VBX]] (acronimo di ''Visual Basic extension'', ''Estensione di Visual Basic'') con [[Visual Basic]] 1.0.

Nel [[1993]] Microsoft rilasciòdistribuì OLE 2, avente COM come modello a oggetti sottostante. Mentre OLE 1 era focalizzata sui documenti compositi, COM ed OLE 2 avevano un indirizzo più generico. Nel [[1994]] furono introdotti i controlli OLE (OCX, [[OLE Control eXtension]], cioè ''Estensione controllo OLE'') quali naturali successori dei controlli VBX; al tempo stesso, Microsoft annunciò che OLE 2 sarebbe stato chiamato semplicemente "'''OLE'''", e che questo non sarebbe più stato un acronimo, ma un vero e proprio nome con cui la compagnia avrebbe indicato le proprie tecnologie ad oggetti.

Successivamente, nell'inizio del [[1996]], Microsoft cambiò nome ad alcune parti di OLE relative ad [[Internet]] in '''[[ActiveX]]''', iniziando così quel processo che l'ha portata a rinominare negli anni tutte le tecnologie OLE in ActiveX, con la sola eccezione della tecnologia di documenti compositi impiegata in [[Microsoft Office]].

Più tardi, in quell'anno, Microsoft rilasciòdistribuì [[Distributed Component Object Model|DCOM]] (acronimo di ''Distributed component object model'', inglese per ''Modello ad oggetti per componenti distribuiti'') quale risposta a [[CORBA]].

==Struttura e funzionamento di COM==

Lo scopo del Component Object Model è quello di permettere la creazione di componenti software binari: sebbene sia stato creato avendo in mente il linguaggio [[C++]], COM è neutrale rispetto al linguaggio di programmazione, cioè si può usare qualunque linguaggio di programmazione per usare componenti COM a runtime. Questa neutralità è ottenuta specificando i formati dei dati e delle chiamate a funzioni con il linguaggio [[Interface Description Language|IDL]], del tutto indipendente. Concettualmente quindi, è un passo in avanti ulteriore rispetto alle librerie a collegamento dinamiche ([[DLL]]). Ogni oggetto COM deve essere unico all'interno del sistema, e viene usato attraverso '''interfacce''' software anche loro globalmente uniche.

Per assicurare l'unicità, il programmatore che crea un nuovo oggetto COM crea un [[GUID]] per lui (un numero identificativo di 128 bit, generato casualmente e che è, ''quasi'' sicuramente, diverso da ogni altro GUID nel sistema) e un GUID per ciascuna delle interfacce che l'oggetto implementa; questi GUID vengono detti CLSID (class ID) se si riferiscono a un oggetto COM e IID (interface ID) se si riferiscono a un'interfaccia. Affinché sia possibile usare un oggetto COM, questo deve essere registrato in Windows nel [[registro di sistema]], vale a dire viene creata una voce nel registro che associa il CLSID del componente al file su disco che lo implementa fisicamente, e a eventuali informazioni di configurazione. Quando un programma richiede un dato componente COM, fa riferimento al CLSID corrispondente: Windows si occuperà di trovare il file su disco (DLL o [[Eseguibile EXE|EXE]]) e caricare il codice necessario. Fatto questo, il programma chiederà al componente appena creato l'accesso a una delle sue interfacce, usando l'IID di quella che gli serve.

===Le interfacce===

Una interfaccia COM è una collezione di funzioni: vale a dire, è una ''classe virtuale pura'', e nella programmazione ad oggetti viene in genere modellata così. Tutte le componenti COM devono come minimo implementare l'[[interfaccia (informatica)|interfaccia]] standard <code>[[IUnknown]]</code>. Infatti, tutte le interfacce COM sono [[Ereditarietà (informatica)|derivate]] dall'interfaccia <code>IUnknown</code>. Essa consiste in tre [[Metodo (programmazione)|metodi]]: <code>AddRef()</code> e <code>Release()</code>, che implementano il [[conteggio dei riferimenti]] (''reference counting'') e controllano il ciclo di vita delle interfacce; e <code>QueryInterface()</code>, che specificando un ''IID'' permette al chiamante di ottenere riferimenti alle varie interfacce fornite dal componente.

Materialmente, un'interfaccia consiste in un [[Puntatore (programmazione)|puntatore]] a una [[tabella di funzioni virtuali]] che contiene una lista di puntatori alle funzioni che implementano i metodi dichiarati nell'interfaccia, nello stesso ordine con cui sono dichiarati. Questa tecnica di passare liste di puntatori a funzione è l'evoluzione diretta di quella usata in [[Object Linking and Embedding|OLE 1.0]] per comunicare con le sue librerie di sistema.

COM specifica molte altre interfacce standard usate per la comunicazione tra componenti. Per esempio, una di queste interfacce è <code>IStream</code>, che è fornita dalle componenti che hanno [[semantica]] di flussi di dati (es. la componente <code>FileStream</code> usata per leggere e scrivere i file).

Essa fornisce i metodi <code>Read</code> e <code>Write</code> per effettuare letture e scritture di flussi. Un'altra interfaccia standard è <code>IOleObject</code>, fornita dai componenti che prevedono di essere collegati o incapsulati dentro un contenitore. <code>IOleObject</code> contiene metodi che permettono ai chiamanti di determinare il rettangolo perimetrale della componente, determinare se la componente supporta operazioni come ''Apri'', ''Salva'', e così via.

Come già detto, COM venne sviluppato avendo in mente il C++, quindi fa largo uso di puntatori. Questo rendeva impossibile l'uso di oggetti COM con linguaggi che non ne hanno, come il [[Visual Basic]], [[Java (linguaggio di programmazione)|Java]] e tutti i linguaggi di scripting; la '''OLE Automation''', fra le altre cose, pose rimedio a questa situazione. Le interfacce a puntatori vennero denominate ''custom interfaces'' e affiancate da nuove interfacce analoghe ma prive di puntatori, basate su array e collezioni di oggetti, denominate ''automation interfaces''; nella versione Automation, l'interfaccia IUnknown viene sostituita da '''IDispatch'''. Uno stesso componente può implementare le stesse interfacce in entrambe le versioni; tuttavia la versione Custom è obbligatoria, mentre la Automation è solo facoltativa.

===Conteggio dei riferimenti===

Il conteggio dei riferimenti (''[[reference counting]]'') viene usato dai componenti COM per sapere quando possono terminare e scaricarsi dalla RAM. Un programma client che utilizza il componente non può procedere con la sua eliminazione quando ha terminato di usarlo, perché potrebbe essere ancora in uso da altri programmi client (del resto in ambiente COM è prevista la possibilità che un client, una volta terminata l'interazione con un componente, passi il puntatore all'interfaccia dello stesso componente ad un altro client). Perciò l'eliminazione di un componente viene gestita da lui stesso attraverso il ''reference counting''; questa tecnica prevede che l'oggetto COM (ovvero il componente), quando passa il puntatore da una sua interfaccia ad un programma client (il che avviene in seguito alla richiesta da parte del client di poter utilizzare quella particolare interfaccia), incrementa di 1 il "reference count". Quando il client termina di utilizzare l'oggetto COM invoca il metodo '''IUnknown::Release()''' che decrementa di 1 il "reference count". Quando un client riceve il puntatore ad una interfaccia da un altro client invoca sull'oggetto COM il metodo '''IUnknown::AddRef()''' che incrementa di 1 lo stesso "reference count". L'oggetto COM si "auto-distruggerà" quando "reference count" è uguale a 0.

===Ereditarietà, contenimento e aggregazione===

Lo standard prevede un meccanismo di ereditarietà ''singola'' che permette a un componente di estendere le funzioni di un altro: ogni interfaccia può ereditare i metodi di una (e solo una) interfaccia preesistente, ma non di modificare o di sostituire i metodi ereditati dall'interfaccia "padre".

Più in generale è prassi abbastanza comune per gli oggetti COM di una certa complessità fare uso di altri oggetti COM al loro interno; si parla di '''contenimento''' di un oggetto COM se il primo si avvale delle sue interfacce senza renderle disponibili al di fuori di esso, e di '''aggregazione''' se invece lo fa.

===RegFree COM===

[[Windows XP]] ha introdotto una nuova modalità di registrazione locale dei componenti COM, chiamata '''Registration-Free COM''' o RegFree COM per brevità. Con questa tecnica le applicazioni non devono più registrare metadati di attivazione e CLSID nel registro di Windows, ma possono specificarli nel loro '''manifest'''; questo può essere un file [[XML]] che risiede nella directory dell'applicazione stessa oppure essere contenuto nell'header del suo file eseguibile, come sezione in formato binario. Quando Windows caricherà l'applicazione e questa farà riferimento ai suoi oggetti COM, la class factory (l'ente che materialmente crea gli oggetti COM) consulterà il manifest dell'applicazione per cercare i GUID specificati e i metadati associati e caricherà quelli forniti con l'applicazione; solo se il manifest non contiene i GUID richiesti consulterà il registro di Windows e (se ne trova installati) creerà gli equivalenti oggetti COM di sistema.

Il limite di questa tecnologia è che non può essere usata con componenti COM che devono essere visibili in tutto il sistema, quindi non si può usare per server COM OutOfProcess o per implementare parti di sistema operativo ([[MDAC]], [[MSXML]], [[DirectX]] o [[Internet Explorer]]).

==Tecnologie correlate==

Line 20 ⟶ 45:

===COM+===

Con [[Windows 2000]], furono introdotte un numero significativo di estensioni COM chiamate '''COM+'''. Nello stesso periodo Microsoft de-enfatizzò [[Distributed Component Object Model|DCOM]] come entità separata.

===DCOM===

Line 29 ⟶ 54:

La piattaforma COM è stata ampiamente sorpassata da [[Microsoft .NET]], ed il marketing di Microsoft è del tutto incentrato su .NET; in un certo senso, COM adesso è addirittura [[deprecato]] a favore di .NET. Nonostante ciò, COM rimane una tecnologia importante per via della sua massiccia base software – per esempio, l'[[software development kit|SDK]] [[DirectX]] è basato su COM; inoltre, un componente COM è teoricamente sempre più prestante di un corrispondente componente gestito .NET{{citazione necessaria}}. Al momento della redazione di questa voce, Microsoft non ha annunciato di aver intenzione di ritirare né interrompere il supporto a COM.

Alcuni servizi che fornisce COM+, come le [[transazione (basi di dati)|transazioni]] e [[coda (informatica)|code di componenti]], sono ancora importanti per le applicazioni enterprise di .NET.

C'è un limite alla [[retrocompatibilità]]. Un oggetto COM può essere usato in .NET implementando un ''runtime callable wrapper'' (RCW).

==Sicurezza su Internet==

L'idea della Microsoft di incapsulare il contenuto attivo nelle pagine web sotto forma di componenti COM/ActiveX (anziché, ad esempio, [[applet Java]]) ha creato una serie di problemi nel browser [[Internet Explorer]], che ha portato a un'esplosione di infezioni da [[Virus (informatica)|virus informatici]], [[trojan]] e [[spyware]]. Questi attacchi di [[malware]] devono soprattutto a ActiveX la loro attivazione e propagazione agli altri computer. La Microsoft ha riconosciuto il problema di ActiveX già nel [[1996]], quando [[Charles Fitzgerald]], direttore della squadra Java della Microsoft, ha detto "Se si vuole la sicurezza nella ''Rete'', si scolleghi il computer. (...) Non abbiamo mai sostenuto che ActiveX sia intrinsecamente sicuro."

Poiché le componenti COM e ActiveX sono eseguite come codice nativo sulla macchina dell'utente, ci sono poche restrizioni su ciò che il loro codice può fare. Molti di questi problemi sono stati affrontati dalla relativa deprecazione di COM nelle piattaforme sviluppate da allora, come la [[piattaforma Java]], e in seguito anche la [[Microsoft .NET|piattaforma .NET]].

L'idea della Microsoft di incapsulare il contenuto attivo nelle pagine web sotto forma di componenti COM/ActiveX (anziché, ad esempio, [[applet Java]]) ha creato una serie di problemi nel browser [[Internet Explorer]], che ha portato a un'esplosione di infezioni da [[Virus (informatica)|virus informatici]], [[trojan (informatica)|trojan]] e [[spyware]]. Questi attacchi di [[malware]] devono soprattutto a ActiveX la loro attivazione e propagazione agli altri computer. Microsoft ha riconosciuto il problema di ActiveX già nel [[1996]], quando [[Charles Fitzgerald]], direttore della squadra Java della Microsoft, ha detto "Se si vuole la sicurezza nella ''Rete'', si scolleghi il computer. (...) Non abbiamo mai sostenuto che ActiveX sia intrinsecamente sicuro."

==Dettagli tecnici==

===Interfacce===

Tutte le componenti COM devono come minimo implementare l'[[interfaccia]] standard <code>[[IUnknown]]</code>. Infatti, tutte le interfacce COM sono [[Ereditarietà (informatica)|derivate]] dall'interfaccia <code>IUnknown</code>. Essa consiste in tre [[Metodo (programmazione)|metodi]]: <code>AddRef()</code> e <code>Release()</code>, che implementano il [[conteggio dei riferimenti]] (''reference counting'') e controllano il ciclo di vita delle interfacce; e <code>QueryInterface()</code>, che specificando un ''IID'' permette al chiamante di ottenere riferimenti alle varie interfacce fornite dal componente.

Le interfacce di una componente COM devono godere delle proprietà riflessiva, simmetrica e transitiva.

La proprietà ''riflessiva'' si riferisce alla capacità di una chiamata a <code>QueryInterface()</code> su una certa interfaccia, con l'ID di quell'interfaccia, di restituire la stessa istanza dell'oggetto.

La proprietà ''simmetrica'' prevede che quando l'interfaccia B è prelevata dall'interfaccia A tramite <code>QueryInterface()</code>, l'interfaccia A possa essere altrettanto prelevata da B.

La proprietà ''transitiva'' è simile alla simmetrica, ma prevede che se A può ottenere B e B può ottenere C, allora A deve poter ottenere C.

Un'interfaccia consiste in un [[Puntatore (programmazione)|puntatore]] a una [[tabella di funzioni virtuali|tabella]] di [[Funzione virtuale|funzioni virtuali]] che contiene una lista di puntatori alle funzioni che implementano i metodi dichiarati nell'interfaccia, nello stesso ordine con cui sono dichiarati. Questa tecnica di passare liste di puntatori a funzione è l'evoluzione diretta di quella usata in [[Object Linking and Embedding|OLE 1.0]] per comunicare con le sue librerie di sistema.

COM specifica molte altre interfacce standard usate per la comunicazione tra componenti. Per esempio, una di queste interfacce è <code>IStream</code>, che è fornita dalle componenti che hanno [[semantica]] di flussi di dati (es. la componente <code>FileStream</code> usata per leggere e scrivere i file).

Essa fornisce i metodi <code>Read</code> e <code>Write</code> per effettuare letture e scritture di flussi. Un'altra interfaccia standard è <code>IOleObject</code>, fornita dai componenti che prevedono di essere collegati o incapsulati dentro un contenitore. <code>IOleObject</code> contiene metodi che permettono ai chiamanti di determinare il rettangolo perimetrale della componente, determinare se la componente supporta operazioni come ''Apri'', ''Salva'', e così via.

===Classi===

Una classe in COM è chiamata '''coclasse'''. Una coclasse è il modo di COM, indipendente dal linguaggio, di definire una classe (nel senso della programmazione a oggetti).

Una coclasse fornisce implementazioni '''concrete''' di una o più interfacce. In COM, queste implementazioni possono essere scritte in qualunque linguaggio che supporti lo sviluppo di componenti COM, come C++, Visual Basic, ecc.

Uno dei maggiori contributi di COM al mondo dello sviluppo per Windows è la consapevolezza del concetto di '''separazione dell'interfaccia dall'implementazione'''. Questa consapevolezza ha indubbiamente influenzato il modo in cui i programmatori creano i sistemi al giorno d'oggi. Un'estensione di questo concetto fondamentale è la nozione di '''una interfaccia, tante implementazioni'''. Con questo si intende che, durante l'esecuzione, un'applicazione può scegliere quale interfaccia istanziare tra molte implementazioni concrete disponibili.

===Linguaggio di definizione di interfacce e librerie di tipi===

===COM: un framework per oggetti===

===Registro di sistema===

In Windows, le classi COM, le interfacce e le librerie di tipi sono elencate per i rispettivi GUID nel [[registro di sistema]]; quando un'applicazione richiede il caricamento di una libreria, COM usa il registro per localizzarla, sia che si tratti di una libreria locale, sia che si tratti dell'indirizzo di rete di un servizio remoto.

===Conteggio dei riferimenti===

Il conteggio dei riferimenti (reference counting) è una tecnica che viene utilizzata in ambiente COM per gestire l'eliminazione dei componenti. Nel momento in cui un programma client non ha più la necessità di utilizzare il componente non può procedere con la sua eliminazione dal momento che altri programmi client potrebbero utilizzare in quello stesso momento il componete (del resto in ambiente COM è prevista la possibilità che un client, una volta terminata l'interazione con un componente, passi il puntatore all'interfaccia dello stesso componente ad un altro client). Per questo motivo l'eliminazione di un componente viene gestita dallo stesso componete attraverso il "reference counting". Questa tecnica prevede che l'oggetto COM (ovvero il componente), quando passa il puntatore da una sua interfaccia ad un programma client (questo avviene in seguito alla richiesta da parte del client di poter utilizzare la particolare interfaccia), incrementa di 1 il "reference count". Quando il client termina di utilizzare l'oggetto COM invoca il metodo '''IUnknown::Realease()''' che decrementa di 1 il "reference count". Quando un client riceve il puntatore ad una interfaccia da un altro client invoca sull'oggetto COM il metodo '''IUnknown::AddRef()''' che incrementa di 1 lo stesso "reference count". L'oggetto COM si "auto-distrugge" quando "reference count" è uguale a 0.

===Instanziamento===

===Thread in COM===

==Critiche==

Line 79 ⟶ 67:

===Inizializzazione dell'ambiente===

Per ogni [[Processo (informatica)|thread]] che necessita delle funzionalità di COM, il programmatore deve aggiungere chiamate esplicite alle funzioni <code>CoInitialize[Ex]</code> e <code>CoUninitialize</code>; inoltre, il codice utilizzanteche utilizza gli appunti o il drag & drop OLE deve chiamare <code>OleInitialize</code> e <code>OleUninitialize</code>. Dato che alcuni thread nel sistema possono essere stati creati da librerie che non usano COM, il programmatore deve prestare attenzione nell'usare qualsiasi funzione di COM in un thread che non è stato creato all'interno del programma stesso.

===Smistamento dei messaggi===

Quando un ''Single-Threaded Apartment'' viene inizializzato, crea una finestra nascosta che viene utilizzata per l'indirizzamento dei messaggi ''inter-apartment'' e ''inter-process''. Questa finestra deve avere la sua procedura standard per la gestione dei messaggi. Questo procedimento è noto come smistamento dei messaggi (message pump). Nelle versioni precedenti di Windows, un errore nel fare questo poteva causare un blocco a livello di sistema. Questo problema è ulteriormente complicato da alcune [[Application programming interface|API]] di Windows che inizializzano COM come parte della loro implementazione, che causa a sua volta una mancanza di dettagli dell'implementazione del componente COM.

===Conteggio dei riferimenti===

Uno scenario in cui il reference counting porta a problemi è quello in cui due oggetti COM si riferiscono l'un l'altro, come accade ad esempio usando i ''''connection points'''' o gli ''''event sink''''. In questo caso nessuno dei due oggetti può rilasciare se stesso perché deve prima rilasciare l'altro, che dal canto suo non può farsi rilasciare perché ha ancora un riferimento all'oggetto che vorrebbe rilasciarlo. Questo circolo vizioso si può spezzare in due modi: una terminazione forzata (out-of-band termination) di uno dei due oggetti, oppure la creazione di due oggetti COM identici referenziati debolmente, di cui uno è usato per connettersi al partner di comunicazione e l'altro serve solo per terminare il primo.

Il conteggio dei riferimenti alle varie interfacce è molto importante. Sbagliare per difetto porta a un errore a runtime quando si cerca di disallocare interfacce ancora in uso; sbagliare per eccesso provoca sprechi di memoria, tenendo in RAM parti di codice che non servono più.

===Inferno delle DLL===

Ogni interfaccia COM è anche un contratto fra chiamante e chiamato: un programma che usiusa un componente COM deve assumere che i metodi che chiama si comporteranno sempre come previsto e non ha alcun controllo su di essi. Dal momento che la posizione di ogni componente è memorizzata in un luogo di livello sistema (in Windows nel [[registro di sistema]]), solamente una versione dello stesso componente può essere installata nel sistema in un dato momento, tipicamente la versione che l'ultima applicazione installata ha portato con sé; se il nuovo componente ha proprietà anche solo leggermente diverse da quello precedente, le altre applicazioni genereranno improvvisamente errori e comportamenti imprevedibili o casuali, senza alcun motivo apparente. Questo fenomeno è chiamato "[[Dynamic-link library|DLL]] hell" (''"Inferno delle DLL"''), situazione tristemente nota a programmatori e amministratori di sistema. Con la {{Chiarire|RegFree COM}} di Windows XP questo grave inconveniente può essere drasticamente ridotto.

==Note==

Line 94 ⟶ 83:

== Voci correlate ==

*[[CAPICOM]]

*[[Distributed Component Object Model|Distributed Component Object Model (DCOM)]]

*[[Dynamic Data Exchange|Dynamic Data Exchange (DDE)]]

*[[Microsoft .NET]]

*[[Object Linking and Embedding|Object Linking and Embedding (OLE)]]

*[[OLE for Process Control]]

==Collegamenti esterni==

*{{en}} [https://web.archive.org/web/20041011222635/http://msdn.microsoft.com/library/en-us/dnolegen/html/msdn_aboutole.asp What OLE is Really About] by Kraig Brockschmidt. An Overview of COM and OLE.

*{{en}} [http://www.microsoft.com/com/ Microsoft COM Technologies]

*{{cita web|http://www.research.microsoft.com/comapps/|Component Application Group at Microsoft Research|lingua=en}}

*{{en}} [http://msdn.microsoft.com/library/en-us/dnolegen/html/msdn_aboutole.asp What OLE is Really About] by Kraig Brockschmidt. An Overview of COM and OLE.

*{{cita web|1=http://www.iol.ie/~locka/mozilla/mozilla.htm|2=Mozilla ActiveX Project|lingua=en|accesso=2 maggio 2006|urlarchivio=https://web.archive.org/web/20060721123224/http://www.iol.ie/%7Elocka/mozilla/mozilla.htm|dataarchivio=21 luglio 2006|urlmorto=sì}}

*{{en}} [http://www.research.microsoft.com/comapps/ Component Application Group at Microsoft Research]

*{{en}} [https://web.archive.org/web/20060428072429/http://www.codeproject.com/com/comintro.asp Introduction To Com] - basic introduction on how to use COM-components, CodeProject

*{{en}} [http://www.iol.ie/~locka/mozilla/mozilla.htm Mozilla ActiveX Project]

*{{en}} [https://support.microsoft.com/kb/159621/en-us INFO: Difference Between OLE Controls and ActiveX Controls] from Microsoft

*{{en}} [http://www.codeproject.com/com/comintro.asp Introduction To Com] - basic introduction on how to use COM-components, CodeProject

*{{cita web|1=http://www.codeproject.com/com/CCOMThread.asp|2=Understanding The COM Single-Threaded Apartment Part 1|lingua=en|accesso=2 maggio 2006|urlarchivio=https://web.archive.org/web/20060719003112/http://www.codeproject.com/com/CCOMThread.asp|dataarchivio=19 luglio 2006|urlmorto=sì}}

*{{en}} [http://support.microsoft.com/kb/159621/en-us INFO: Difference Between OLE Controls and ActiveX Controls] from Microsoft

*{{en}}cita [web|1=http://www.codeproject.com/com/CCOMThreadCCOMThread2.asp |2=Understanding The COM Single-Threaded Apartment Part 1]2|lingua=en|accesso=2 maggio 2006|urlarchivio=https://web.archive.org/web/20060614231735/http://www.codeproject.com/com/CCOMThread2.asp|dataarchivio=14 giugno 2006|urlmorto=sì}}

*{{cita web|1=http://www.codeproject.com/useritems/BuildCOMServersInDotNet.asp|2=Building COM Servers in .NET|lingua=en|accesso=2 maggio 2006|urlarchivio=https://web.archive.org/web/20060717235730/http://www.codeproject.com/useritems/BuildCOMServersInDotNet.asp|dataarchivio=17 luglio 2006|urlmorto=sì}}

*{{en}} [http://www.codeproject.com/com/CCOMThread2.asp Understanding The COM Single-Threaded Apartment Part 2]

*{{en}} [http://www.codeproject.com/useritems/BuildCOMServersInDotNet.asp Building COM Servers in .NET]

{{Componenti di Windows}}

{{Portale|informatica}}

{{Controllo di autorità}}

{{portale|informatica|microsoft}}

[[Categoria:Software di sistema]]

[[Categoria:Linguaggi di programmazione]]

[[Categoria:Microsoft]]

[[da:COM (software)]]

[[de:Component Object Model]]

[[en:Component Object Model]]

[[es:Component Object Model]]

[[fr:Component Object Model]]

[[he:COM]]

[[hu:Component Object Model]]

[[ja:Component Object Model]]

[[ko:컴포넌트 오브젝트 모델]]

[[nl:Component Object Model]]

[[pl:Component Object Model]]

[[pt:Component Object Model]]

[[ru:Component Object Model]]

[[sv:Component Object Model]]

[[uk:Component Object Model]]

[[zh:组件对象模型]]