Qu'est-ce que COM / ActiveX / OCX ? - Différences et relations expliquées ensemble

Les trois mots COM / ActiveX / OCX apparaissent presque toujours ensemble dans les projets Windows hérités.

• Un éditeur vous envoie un fichier .ocx
• Un composant mystérieux se trouve sur un formulaire Access ou VB6
• Quelqu’un dit « c’est du COM », immédiatement suivi de « c’est de l’ActiveX »
• Puis regsvr32, 32 bits / 64 bits, et le mode IE arrivent tous en même temps

À ce moment-là, la conversation s’enlise généralement. Les termes sont proches les uns des autres, et historiquement ils se chevauchent fortement. À l’inverse, une fois que l’on parvient à les distinguer, l’investigation, la migration et l’explication deviennent nettement plus faciles.

Dans cet article, nous clarifions ce qu'est COM, ce qu'est ActiveX, et ce qu'est OCX, dans un ordre qui rend visibles les différences et les relations. En particulier, nous précisons lequel est le socle, lequel est le composant, et lequel est le fichier.

Sommaire

1. La conclusion d’abord (en une ligne)
2. Ce que cet article entend par COM / ActiveX / OCX
3. Une vue d’ensemble en une page
   • 3.1. Schéma de relation
   • 3.2. Le glossaire le plus court
4. Qu’est-ce que COM ?
   • 4.1. En une phrase
   • 4.2. Ce qui compte dans COM
5. Qu’est-ce qu’ActiveX ?
   • 5.1. En une phrase
   • 5.2. ActiveX n’est pas réservé au navigateur
6. Qu’est-ce qu’OCX ?
   • 6.1. En une phrase
   • 6.2. En quoi cela diffère d’un .dll
7. Les différences dans un tableau
8. Où étaient-ils utilisés
9. Pourquoi sont-ils si facilement confondus
10. Comment les envisager aujourd’hui en pratique
11. Idées reçues courantes
12. Points de contrôle lors d’une investigation
13. Résumé
14. Références

1. La conclusion d’abord (en une ligne)

Voici d’abord la version approximative mais utile.

• COM est le socle : le contrat binaire qui permet aux composants de communiquer entre eux sous Windows
• ActiveX est le contexte des composants basés sur COM : il apparaît le plus souvent sous forme de contrôles intégrés dans un hôte
• OCX est le fichier d’implémentation couramment rencontré pour les contrôles ActiveX : on le rencontre comme extension de fichier
• Autrement dit, COM = le mécanisme, ActiveX = le contexte du composant, OCX = le fichier est un cadre qui garde les choses claires
• Le souvenir de ActiveX = ce vieux truc dangereux du navigateur est à moitié juste et à moitié incomplet. ActiveX n’est pas réservé au navigateur
• OCX = ActiveX est souvent utilisé de façon presque interchangeable, mais à strictement parler cela mélange un concept et une extension de fichier
• Ce n’est pas une technologie autour de laquelle on bâtirait un nouveau développement aujourd’hui, mais on la rencontre encore dans les applications Windows existantes, Office, Access, les SDK de matériel et les systèmes web internes

Tout commence par distinguer ces trois questions.

1. S’agit-il d’une question sur COM ?
2. S’agit-il d’une question sur un contrôle ActiveX ?
3. Ou bien s’agit-il simplement d’une personne qui l’appelle ainsi parce qu’elle a vu un fichier .ocx ?

Une fois que vous savez faire la différence, une bonne partie du brouillard se dissipe.

2. Ce que cet article entend par COM / ActiveX / OCX

En pratique, ces trois termes cohabitent souvent de façon assez lâche. Cet article fixe donc d’abord les significations.

• COM : le modèle de composants Windows lui-même. Le socle des interfaces, des GUID, de l’enregistrement et de l’invocation
• ActiveX : les contrôles intégrables construits sur COM, et le contexte dans lequel ils sont utilisés. En pratique, cela désigne le plus souvent les contrôles ActiveX
• OCX : l’extension de fichier couramment observée pour les implémentations de contrôles ActiveX. .ocx

Une petite mise en garde : historiquement, le mot ActiveX a été utilisé de façon un peu plus large pendant un temps. Mais les endroits où ActiveX pose problème dans la pratique actuelle tournent presque tous autour des contrôles, de l’intégration, des hôtes, des navigateurs et de l’enregistrement.

Cet article avance donc également avec comme base ActiveX ≈ le côté contrôle ActiveX de l’histoire.

3. Une vue d’ensemble en une page

3.1. Schéma de relation

Le plus rapide est de voir l’ensemble du tableau sur une seule page.

flowchart LR
    COM["COM<br/>Socle des contrats binaires"] --> OLE["OLE / Automation<br/>Mécanismes d'intégration et d'automatisation"]
    OLE --> AX["ActiveX<br/>Contexte de contrôle basé sur COM"]
    AX --> CTRL["Contrôle ActiveX"]
    CTRL --> OCX["OCX (.ocx)<br/>Forme de fichier d'implémentation courante"]

    HOST["Hôte / conteneur<br/>IE / Access / VB6 / MFC / WinForms"] --> CTRL

Le point important ici est que COM et ActiveX ne sont pas le même mot.

• COM est le socle
• OLE / Automation sont les mécanismes d’intégration et d’automatisation
• ActiveX apparaît comme le contexte de contrôle utilisé au-dessus d’eux
• OCX est le fichier que l’on rencontre couramment pour ces implémentations de contrôles

Donc si quelqu’un demande ActiveX est-il la même chose que COM ?, la réponse est : le socle est COM, mais ActiveX n’est pas COM lui-même.

3.2. Le glossaire le plus court

Si vous ne retenez que la version la plus courte, cela suffit.

• COM est le mécanisme
• ActiveX est le contexte du composant
• OCX est le fichier

4. Qu’est-ce que COM ?

4.1. En une phrase

COM signifie Component Object Model : le contrat binaire qui permet aux composants de communiquer entre eux sous Windows.

Par contrat binaire, on entend une interface dont les promesses tiennent même sous forme compilée, indépendamment des arrangements du code source ou des spécificités du langage. Un composant écrit en C++ peut être utilisé depuis un autre langage ou une autre application précisément parce que ce contrat existe.

En termes pratiques, COM est moins une manière de distribuer des bibliothèques pratiques et plutôt un mécanisme qui cache l’implémentation et connecte les choses par le seul contrat.

Voici les caractéristiques typiques de COM :

• Le comptage de références via IUnknown
• La découverte d’interface via QueryInterface
• L’identification par GUID via IID et CLSID
• L’utilisation en processus (in-process) via des DLL
• L’utilisation hors processus (out-of-process) via des EXE

En résumé, COM est le socle de la culture de componentisation sous Windows.

4.2. Ce qui compte dans COM

Si l’on s’en tient à l’essentiel, voici ce qui compte dans COM.

• Conception centrée sur l’interface
  • Vous décidez ce que vous exposez avant de décider comment l’implémenter
• Identification par GUID
  • Les classes et les interfaces sont identifiées de manière unique
• Séparation entre l’hôte et l’implémentation
  • L’appelant n’a pas besoin de connaître l’implémentation interne
• Franchissement des frontières de processus
  • Les composants peuvent être utilisés non seulement dans le même processus, mais aussi comme composants d’un autre processus

C’est ce qui empêche COM de n’être qu’une vieille technologie parmi d’autres. Dès une époque remarquablement précoce, COM avait une prise solide sur une conception réutilisable, basée sur le contrat.

5. Qu’est-ce qu’ActiveX ?

5.1. En une phrase

ActiveX se comprend le mieux comme des composants logiciels réutilisables construits sur COM - en particulier, des contrôles intégrés dans des hôtes ou des conteneurs.

Quand on dit ActiveX en pratique, il est très probable qu’on parle de contrôles ActiveX : des éléments comme des boutons, des grilles, des graphiques, des calendriers, des visionneuses, et des composants d’intégration avec du matériel.

ActiveX est moins une technologie gigantesque se tenant fièrement seule et plutôt un composant qui fonctionne intégré dans un hôte - envisager les choses ainsi vous égare rarement.

5.2. ActiveX n’est pas réservé au navigateur

L’impression que ActiveX = ce truc d'Internet Explorer est très forte. Ce n’est pas faux - mais ce n’est pas toute l’histoire.

Voici les endroits où les contrôles ActiveX ont été utilisés :

• Les formulaires Access
• Les applications VB6
• Les conteneurs MFC
• L’environnement d’Office / VBA
• Les contrôles ActiveX existants encapsulés pour être utilisés depuis WinForms
• Internet Explorer et ses opérations en mode de compatibilité

Autrement dit, ActiveX n’est pas une technologie réservée au navigateur - elle est aussi utilisée depuis longtemps du côté des applications Windows.

Si l’on manque ce point, on finit par traiter l’ActiveX trouvé dans un système web interne et l’ActiveX intégré dans un formulaire Access comme des choses différentes. En réalité, les deux sont des parents très proches, basés sur COM.

6. Qu’est-ce qu’OCX ?

6.1. En une phrase

OCX est l’extension de fichier couramment utilisée pour les implémentations de contrôles ActiveX. Si vous trouvez un .ocx dans un environnement Windows, votre premier soupçon devrait être un composant COM intégrable, de type contrôle.

Les endroits typiques où on le rencontre :

• Les distributions de SDK d’éditeurs
• Les anciens projets VB6 / Access / MFC
• Les fichiers qu’un installateur doit enregistrer
• Les composants qui nécessitent regsvr32

Ce qu’il faut retenir, c’est qu’OCX est un format de fichier, pas le concept lui-même. Donc, pour une réponse approximative à qu'est-ce qu'OCX, c’est : le fichier que l’on rencontre le plus souvent comme forme physique d’un contrôle ActiveX.

6.2. En quoi cela diffère d’un .dll

C’est un autre point de confusion fréquent.

• Un .ocx suggère fortement un contrôle ActiveX
• Un .dll peut être une bibliothèque ordinaire, un serveur COM, ou une DLL de dépendance autour d’un composant ActiveX

Voir un .ocx permet de deviner qu’il s’agit de quelque chose de proche d’ActiveX ; voir un .dll seul ne dit encore rien de ce qu’il est.

Un schéma courant sur le terrain est un ensemble tel que

• vendorcontrol.ocx
• vendorhelper.dll
• vendorcore.dll

où l’OCX est le premier rôle et les DLL jouent des rôles de soutien.

Donc si on demande un OCX est-il une sorte de DLL ? - intuitivement, oui, c’est proche - mais lors d’une investigation, il est plus sûr de regarder les rôles séparément.

7. Les différences dans un tableau

Si vous ne retenez qu’une chose de ce tableau, commencez ici.

• COM est le gros œuvre
• ActiveX est la culture de composants construite dessus
• OCX est le fichier que l’on ramasse sur le terrain

8. Où étaient-ils utilisés

Parce que les souvenirs liés au navigateur sont si vivaces, ActiveX / OCX ont tendance à ressembler à une vieille technologie web. En réalité, ils étaient utilisés bien plus largement.

Concrètement, dans des endroits comme ceux-ci :

• Applications de bureau
  • VB6
  • MFC / C++
  • Formulaires Access
  • Environnement d’Office / VBA
• Navigateurs / systèmes web internes
  • Visionneuses intégrées dans Internet Explorer
  • Composants de signature
  • Composants de transfert de fichiers
  • Composants d’intégration de périphériques
• Applications .NET existantes
  • Contrôles ActiveX existants encapsulés pour être utilisés depuis WinForms
  • Ressources COM existantes maintenues en vie comme composants d’interface utilisateur

Ce qui nous ramène, une fois de plus, au fait qu’ActiveX n’est pas réservé à l’internet. Cela ressemble seulement à une technologie web parce qu’elle a été très visible dans IE ; en substance - et de façon plus utile en pratique - il est plus juste de la voir comme une technologie de composants intégrables pour Windows.

9. Pourquoi sont-ils si facilement confondus

9.1. Des niveaux de langage différents, mais la même conversation

• COM est une question de socle
• ActiveX est une question de contexte du composant
• OCX est une question de fichier

Ils se situent d’emblée à des niveaux différents, mais en pratique ils apparaissent tous sur le même terrain au même moment - les conversations s’emmêlent donc facilement.

9.2. Le mot ActiveX est un peu large

COM a un sens relativement fixe. ActiveX, en revanche, est utilisé de façon un peu large, aussi bien historiquement qu’en pratique.

Selon la personne, cela peut désigner

• le contrôle lui-même
• le fichier .ocx
• un ancien composant qui s’exécute dans IE
• les composants intégrables basés sur COM en général

et ces références divergent. À ce stade, la conversation ne s’aligne déjà plus.

9.3. Dès qu’on voit un .ocx, on a envie de tout appeler ActiveX

On comprend le réflexe. Et pour une conversation du quotidien, cela fonctionne généralement.

Mais pour une migration ou une investigation, à moins de vérifier séparément

• s’il s’agit d’un composant d’interface utilisateur
• dans quel hôte il s’exécute
• s’il a besoin d’un enregistrement
• quelle est la situation en 32 bits / 64 bits
• s’il existe une dépendance au navigateur

vous trébucherez plus tard - c’est garanti.

10. Comment les envisager aujourd’hui en pratique

D’abord : trouver du COM / ActiveX / OCX ne signifie pas qu’il faut immédiatement tout rejeter. Mais traiter tout cela avec la même température est également dangereux.

Dépendances ActiveX côté navigateur

Celles-ci sont plus sûres à examiner sévèrement, et en priorité.

• Elles ne font pas partie du courant dominant du développement de navigateur moderne
• Le mode IE revient dans les contextes d’exploitation en compatibilité, mais il est préférable de le voir comme un pont pour la compatibilité ascendante
• L’adopter comme prémisse pour quoi que ce soit de nouveau est difficile à recommander

Pour l’ActiveX côté web, il est plus réaliste de penser en termes de « par où commencer à s’en détacher » plutôt que « comment le maintenir en vie ».

Dépendances ActiveX / OCX côté bureau

Celles-ci peuvent être jugées de façon un peu plus pragmatique.

• Le composant fonctionne de manière stable dans un hôte existant
• Les cibles de diffusion sont limitées
• Il existe une perspective de maintenance, qu’elle soit assurée par l’éditeur ou en interne
• L’enregistrement, les DLL de dépendance et les hypothèses de bitness sont compris

Si ces conditions sont réunies, le conserver est une décision tout à fait normale.

En revanche, si

• vous voulez charger un OCX 32 bits directement dans un processus 64 bits
• vous voulez déplacer uniquement le code environnant vers .NET
• la diffusion et l’enregistrement vous font trébucher à chaque fois
• une dépendance au navigateur subsiste

alors il est plus sûr d’envisager conserver / envelopper / remplacer comme des options distinctes.

Ce que la pratique actuelle demande vraiment, ce n’est pas de savoir si ActiveX est donc mauvais, mais où tracer la frontière. Vu moins comme une vieille technologie et plus comme la surface de jonction d’un système existant, cela devient beaucoup plus facile à gérer.

11. Idées reçues courantes

Idée reçue 1 : COM = ActiveX

Non. COM est le socle ; ActiveX est le contexte de contrôle utilisé au-dessus de lui.

Idée reçue 2 : ActiveX = Internet Explorer

Non. Il est vrai qu’IE l’a rendu célèbre, mais ActiveX n’est pas réservé au navigateur.

Idée reçue 3 : ActiveX = OCX

En pratique, ils sont utilisés dans des sens très proches, mais à strictement parler ils diffèrent. ActiveX concerne le contexte et les composants ; OCX est la forme physique que l’on rencontre comme extension de fichier.

Idée reçue 4 : un OCX n’est qu’une simple DLL, non ?

Grossièrement dit, c’est proche - mais ne soyez pas approximatif à ce sujet lors d’une investigation. Un .dll seul ne dit rien de son rôle, alors qu’un .ocx sent fortement le contrôle.

Idée reçue 5 : COM est une technologie morte

Dans le monde Windows tout du moins, c’est le dire de façon trop grossière. Il s’est simplement retiré du devant de la scène ; il apparaît encore aujourd’hui dans les contextes de conception et d’interopérabilité.

12. Points de contrôle lors d’une investigation

Quand vous trouvez du COM / ActiveX / OCX, parcourir ces points dans l’ordre vous évite de vous perdre.

1. De quel type de composant s’agit-il ?
   • Un contrôle d’interface utilisateur ?
   • Une visionneuse ?
   • Une intégration de matériel ?
   • Une intégration Office / Access ?
2. Où s’exécute-t-il ?
   • Access / VBA ?
   • VB6 / MFC ?
   • WinForms ?
   • IE / mode IE ?
3. Quels sont les fichiers et les identifiants ?
   • .ocx / .dll / .exe
   • ProgID
   • CLSID
   • Type Library
4. Comment l’enregistrement et la diffusion sont-ils gérés ?
   • regsvr32 est-il requis ?
   • Y a-t-il des DLL de dépendance ?
   • Des droits administrateur sont-ils requis ?
5. La bitness correspond-elle ?
   • 32 bits ?
   • 64 bits ?
   • Doit-il s’exécuter dans le même processus ?
6. Comment sera-t-il traité à l’avenir ?
   • Le conserver tel quel ?
   • Tracer une frontière et l’envelopper ?
   • Le remplacer ?

Foncez avec un il y a de l'ActiveX ici, donc on va tout réimplémenter depuis zéro sans regarder ces points, et vous marcherez sur tous les pièges classiques du manuel. Il n’est pas nécessaire de pratiquer la réflexologie dans un champ de mines.

13. Résumé

La façon la plus grossière - mais la plus utile en pratique - d’énoncer les différences entre COM / ActiveX / OCX est celle-ci.

• COM est le socle
• ActiveX est le contexte des composants intégrables basés sur COM
• OCX est le fichier que l’on rencontre couramment pour les contrôles ActiveX

Une fois que vous parvenez à distinguer ces trois éléments, il devient beaucoup plus facile de voir

• s’il s’agit simplement d’un .ocx
• s’il s’agit d’un problème lié à COM dans son ensemble
• s’il s’agit d’un ActiveX dépendant du navigateur
• s’il s’agit d’un composant qui peut rester sur le bureau

La technologie héritée n’est pas difficile parce que les noms sont anciens - elle est déroutante parce que le socle, les composants et les fichiers apparaissent tous dans la même conversation. Mais une fois la structure visible, c’est un problème étonnamment gérable.

14. Références

• Qu’est-ce que COM ? - Pourquoi la conception de COM sous Windows est encore magnifique
• Comment traiter ActiveX / OCX aujourd’hui - Un tableau de décision conserver / envelopper / remplacer
• Component Object Model (COM) - Microsoft Learn
• ActiveX Controls - Win32 apps - Microsoft Learn
• ActiveX Controls - MFC - Microsoft Learn
• ActiveX Control - Access VBA - Microsoft Learn
• What is Internet Explorer (IE) mode? - Microsoft Learn
• Use DevTools in Internet Explorer mode (IE mode) - Microsoft Learn

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

COM et ActiveX sont-ils la même chose ?

Non. COM (Component Object Model) est le socle : le contrat binaire qui permet aux composants de communiquer entre eux sous Windows, avec des caractéristiques comme le comptage de références via IUnknown, QueryInterface, et l'identification par GUID. ActiveX est le contexte des composants intégrables basés sur COM construits sur ce socle, et en pratique cela désigne le plus souvent des contrôles ActiveX placés dans un hôte comme Access, VB6, MFC ou un navigateur. Un raccourci utile est : COM est le mécanisme, ActiveX est le contexte du composant, et OCX est le fichier.

ActiveX est-il uniquement une ancienne technologie d'Internet Explorer ?

Non. IE a rendu ActiveX célèbre, mais ce n'est pas une technologie réservée au navigateur. Les contrôles ActiveX sont utilisés depuis longtemps du côté des applications Windows : dans les formulaires Access, dans les applications VB6, dans les conteneurs MFC, autour d'Office et de VBA, et encapsulés pour être utilisés depuis WinForms. Considérer que l'ActiveX trouvé dans un système web interne et l'ActiveX intégré dans un formulaire Access sont deux choses différentes est une erreur courante - les deux sont des parents très proches, basés sur COM, et il est plus juste de voir ActiveX comme une technologie de composants intégrables pour Windows.

Qu'est-ce qu'un fichier OCX, et n'est-ce qu'une simple DLL ?

OCX est l'extension de fichier couramment utilisée pour les implémentations de contrôles ActiveX, donc trouver un .ocx doit vous faire suspecter un composant COM intégrable, de type contrôle - typiquement issu de kits SDK fournis par un éditeur, d'anciens projets VB6/Access/MFC, ou d'installateurs qui exécutent regsvr32. Intuitivement, un OCX se rapproche d'une sorte de DLL, mais lors d'une investigation, il est plus sûr de garder les rôles séparés : un .ocx suggère fortement un contrôle ActiveX, tandis qu'un .dll seul pourrait être une bibliothèque ordinaire, un serveur COM, ou une dépendance de support.

COM est-il une technologie morte, et que faire si je trouve COM/ActiveX/OCX dans mon système ?

COM n'est pas mort - il s'est simplement retiré du devant de la scène, mais il apparaît encore aujourd'hui dans les contextes de conception et d'interopérabilité de Windows. Trouver ces composants ne signifie pas que tout doit être rejeté ou réécrit. Les dépendances ActiveX côté navigateur méritent un examen sévère en priorité, car le mode IE est mieux vu comme un pont de compatibilité ascendante. Les dépendances côté bureau peuvent être jugées de façon plus pragmatique : si le composant fonctionne de manière stable, que la diffusion est limitée, et que les hypothèses d'enregistrement et de bitness sont comprises, le conserver est une décision tout à fait normale ; sinon, envisagez conserver, envelopper ou remplacer comme options distinctes.

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.