Was sind COM / ActiveX / OCX? – Unterschiede und Zusammenhänge im Überblick

COM / ActiveX / OCX – diese drei Begriffe tauchen in Windows-Legacy-Projekten meist im Paket auf.

• Ein Hersteller schickt eine .ocx
• Auf einem Access- oder VB6-Formular sitzt ein rätselhaftes Bauteil
• Direkt nachdem jemand sagt „das ist COM“, heißt es „das ist doch ActiveX“
• Danach kommen regsvr32, 32 Bit/64 Bit und der IE-Modus alle auf einmal ins Gespräch

Ab diesem Punkt läuft das Gespräch meist auseinander. Die Begriffe liegen nah beieinander, und historisch überschneiden sie sich stark. Umgekehrt gilt: Kann man sie sauber trennen, werden Recherche, Migration und Erklärung deutlich einfacher.

Dieser Artikel ordnet was COM ist, was ActiveX ist und was OCX ist in einer Reihenfolge, in der Unterschiede und Zusammenhänge sichtbar werden. Insbesondere wird klar, welches das Fundament, welches das Bauteil und welches die Datei ist.

Inhaltsverzeichnis

1. Zuerst das Fazit (in einem Satz)
2. Was dieser Artikel unter COM / ActiveX / OCX versteht
3. Erst einmal auf einen Blick
   • 3.1. Beziehungsdiagramm
   • 3.2. Die kürzeste Begriffsübersicht
4. Was ist COM?
   • 4.1. Kurz gesagt
   • 4.2. Was bei COM wichtig ist
   • 4.3. Kurznotizen zu den Begriffen
5. Was ist ActiveX?
   • 5.1. Kurz gesagt
   • 5.2. ActiveX ist nicht browserspezifisch
6. Was ist OCX?
   • 6.1. Kurz gesagt
   • 6.2. Der Unterschied zu .dll
7. Die Unterschiede in einer Tabelle
8. Wo es eingesetzt wurde
9. Warum es leicht verwechselt wird
10. Wie man es in der heutigen Praxis einordnen sollte
11. Häufige Missverständnisse
12. Checkpoints für die Recherche
13. Zusammenfassung
14. Quellen

1. Zuerst das Fazit (in einem Satz)

Grob, aber nützlich formuliert, sieht das so aus.

• COM ist das Fundament: der binäre Vertrag, über den Komponenten unter Windows miteinander kommunizieren
• ActiveX ist der COM-basierte Bauteil-Kontext: er tritt vor allem als Steuerelement auf, das in einen Host eingebettet wird
• OCX ist die Implementierungsdatei, die man bei ActiveX-Steuerelementen häufig sieht: sie begegnet einem als Dateiendung
• Kurz: COM = der Mechanismus, ActiveX = der Bauteil-Kontext, OCX = die Datei – mit diesem Rahmen bleibt es übersichtlich
• Die Erinnerung ActiveX = das gefährliche alte Browser-Ding ist halb richtig und halb unvollständig. ActiveX ist nicht auf Browser beschränkt
• OCX = ActiveX wird oft nahezu gleichbedeutend verwendet, streng genommen vermischt das aber ein Konzept mit einer Dateiendung
• Es ist keine Technologie, auf die man heute neue Entwicklung aufbaut, aber man begegnet ihr noch in bestehenden Windows-Anwendungen, Office, Access, Geräte-SDKs und internen Webanwendungen

Der Ausgangspunkt ist, diese drei Fragen auseinanderzuhalten.

1. Geht es um COM?
2. Geht es um ein ActiveX-Steuerelement?
3. Oder nennt jemand es nur so, weil eine .ocx-Datei aufgetaucht ist?

Ist das klar, lichtet sich der Nebel erheblich.

2. Was dieser Artikel unter COM / ActiveX / OCX versteht

In der Praxis leben diese drei Begriffe oft recht unordentlich nebeneinander. Deshalb legt dieser Artikel zunächst die Bedeutungen fest.

• COM: das Windows-Komponentenmodell selbst. Das Fundament aus Interfaces, GUIDs, Registrierung und Aufruf
• ActiveX: auf COM aufbauende, einbettbare Steuerelemente und ihr Nutzungskontext. In der Praxis meist gleichbedeutend mit ActiveX-Steuerelementen
• OCX: die Dateiendung, die bei ActiveX-Steuerelement-Implementierungen häufig zu sehen ist. .ocx

Eine kleine Ergänzung: historisch wurde der Begriff ActiveX zeitweise etwas breiter verwendet. Die Stellen, an denen ActiveX in der heutigen Praxis für Verwirrung sorgt, drehen sich aber fast immer um Steuerelemente, Einbettung, Hosts, Browser und Registrierung.

Deshalb geht auch dieser Artikel grundsätzlich von ActiveX ≈ ActiveX-Steuerelement aus.

3. Erst einmal auf einen Blick

3.1. Beziehungsdiagramm

Am schnellsten sieht man das Gesamtbild auf einen Blick. Wer die Grafik nicht angezeigt bekommt, findet direkt darunter dieselbe Information als Aufzählung.

flowchart LR
    COM["COM<br/>Fundament des binären Vertrags"] --> OLE["OLE / Automation<br/>Mechanismen für Einbettung und Automatisierung"]
    OLE --> AX["ActiveX<br/>COM-basierter Steuerelement-Kontext"]
    AX --> CTRL["ActiveX-Steuerelement"]
    CTRL --> OCX["OCX (.ocx)<br/>Häufige Form der Implementierungsdatei"]

    HOST["Host / Container<br/>IE / Access / VB6 / MFC / WinForms"] --> CTRL

Wichtig ist hier: COM und ActiveX sind nicht dasselbe Wort.

• COM ist das Fundament
• OLE / Automation ist der Mechanismus für Einbettung und Automatisierung
• ActiveX tritt als der darauf aufbauende Steuerelement-Kontext auf
• OCX ist die Datei, die man bei dieser Steuerelement-Implementierung häufig sieht

Fragt jemand also Ist ActiveX dasselbe wie COM?, lautet die Antwort: das Fundament ist COM, aber ActiveX ist nicht COM selbst.

3.2. Die kürzeste Begriffsübersicht

Für die kürzeste Merkregel reicht das.

• COM ist der Mechanismus
• ActiveX ist der Bauteil-Kontext
• OCX ist die Datei

4. Was ist COM?

4.1. Kurz gesagt

COM steht für Component Object Model und ist der binäre Vertrag, über den Komponenten unter Windows miteinander kommunizieren.

Mit binärem Vertrag ist hier nicht eine Frage des Quellcodes oder der Sprachspezifikation gemeint, sondern eine Schnittstelle, deren Zusagen auch in kompilierter Form bestehen bleiben. Dass sich ein in C++ gebautes Bauteil aus einer anderen Sprache oder einer anderen Anwendung heraus verwenden lässt, liegt genau an diesem Vertrag.

Praktisch gesehen ist COM weniger eine Art, praktische Bibliotheken zu verteilen als vielmehr ein Mechanismus, der die Implementierung verbirgt und nur über den Vertrag verbindet.

Diese Punkte sind zum Beispiel typisch für COM (die Bedeutung der einzelnen Begriffe ist in 4.3 jeweils in einer Zeile zusammengefasst):

• Referenzzählung über IUnknown
• Interface-Suche über QueryInterface
• GUID-basierte Identifikation über IID und CLSID
• Inprozess-Nutzung über DLLs
• Out-of-Prozess-Nutzung über EXEs

Kurz gesagt: COM ist das Fundament der Komponentenkultur unter Windows.

4.2. Was bei COM wichtig ist

Beschränkt man sich auf die Grundlagen, ist bei COM Folgendes wichtig.

• Interface-zentriert
  • Was veröffentlicht wird, wird vor der Implementierung festgelegt
• Identifikation über GUID
  • Klassen und Interfaces werden eindeutig identifiziert
• Trennung von Host und Implementierung
  • Die aufrufende Seite muss die interne Implementierung nicht kennen
• Prozessgrenzen überschreitbar
  • Bauteile lassen sich nicht nur im selben Prozess, sondern auch als Bauteile eines anderen Prozesses nutzen

Das ist der Grund, warum COM nicht einfach eine alte Technologie von gestern ist. Schon sehr früh war ein solides vertragsbasiertes, wiederverwendbares Design fest verankert.

4.3. Kurznotizen zu den Begriffen

Bei COM fliegen einem ohne weitere Erklärung sofort folgende Begriffe um die Ohren. Hier folgt zum Einstieg nur je eine Zeile pro Begriff. Wer bis zur gestalterischen Eleganz vordringen möchte, findet das in „Was ist COM? – Warum das Design von Windows COM auch heute noch schön ist“.

Dieser Artikel bleibt bei der begrifflichen Einordnung, auf die Details der einzelnen Punkte geht er nicht ein. Wird es später konkret, lassen sich die Begriffe aus dieser Tabelle direkt als Suchbegriffe verwenden.

5. Was ist ActiveX?

5.1. Kurz gesagt

ActiveX lässt sich am einfachsten als auf COM aufbauendes, wiederverwendbares Softwarebauteil verstehen, insbesondere als Steuerelement, das in einen Host oder Container eingebettet wird.

Sagt jemand in der Praxis ActiveX, ist damit ziemlich sicher ein ActiveX-Steuerelement gemeint. Das betrifft zum Beispiel Schaltflächen, Tabellen, Diagramme, Kalender, Viewer oder Bauteile für die Gerätekopplung.

ActiveX lässt sich weniger treffend als große, für sich allein stehende Technologie verstehen, sondern eher als Bauteil, das eingebettet in einem Host arbeitet – mit diesem Bild liegt man selten falsch.

5.2. ActiveX ist nicht browserspezifisch

Der Eindruck ActiveX = das Internet-Explorer-Ding ist sehr stark. Das ist nicht falsch, aber das ist nicht alles.

Hier einige Orte, an denen ActiveX-Steuerelemente verwendet wurden.

• Access-Formulare
• VB6-Anwendungen (Visual Basic 6.0)
• MFC-Container (Microsoft Foundation Class Library)
• rund um Office/VBA
• COM-Wrapper-Nutzung aus WinForms heraus
• Internet Explorer und sein Kompatibilitätsbetrieb

Kurz: ActiveX ist keine reine Browser-Technologie, sondern eine Bauteil-Technologie, die auch auf der Windows-Anwendungsseite lange verwendet wurde.

Ist das nicht klar, behandelt man ActiveX, das man in einer internen Webanwendung findet, und ActiveX, das in ein Access-Formular eingebettet ist, fälschlich als zwei verschiedene Dinge. In Wirklichkeit sind beide recht enge, COM-nahe Verwandte.

6. Was ist OCX?

6.1. Kurz gesagt

OCX ist die Dateiendung, die häufig für die Implementierung von ActiveX-Steuerelementen verwendet wird. Findet man in der Windows-Praxis eine .ocx, darf man zunächst ein eingebettetes, steuerelementartiges COM-Bauteil vermuten.

Sie taucht meist an diesen Stellen auf.

• Auslieferungen eines Hersteller-SDKs
• alte VB6-/Access-/MFC-Projekte
• Registrierungsziele in einem Installationsprogramm
• Bauteile, die regsvr32 benötigen

Wichtig ist: OCX ist eine Dateiform, nicht das Konzept selbst. Grob gesagt lautet die Antwort auf Was ist OCX? also: die Datei, der man als physische Form eines ActiveX-Steuerelements am häufigsten begegnet.

6.2. Der Unterschied zu .dll

Auch das ist eine häufige Quelle von Verwirrung.

• .ocx deutet ziemlich stark auf ein ActiveX-Steuerelement hin
• .dll kann eine gewöhnliche Bibliothek sein, ein COM-Server oder eine abhängige DLL rund um ActiveX

Sieht man eine .ocx, lässt sich ziemlich sicher auf ActiveX-Nähe schließen; eine .dll allein verrät noch nicht, worum es sich handelt.

In der Praxis ist es üblich, dass es so aussieht:

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

wobei die OCX die Hauptrolle spielt und die DLLs unterstützend zur Seite stehen.

Fragt man also Ist OCX quasi eine Art DLL?, liegt das gefühlt nahe – bei Recherche und Migration ist es aber sicherer, die Rollen getrennt zu betrachten.

7. Die Unterschiede in einer Tabelle

Wer sich an dieser Tabelle orientieren möchte, sollte hiermit beginnen.

• COM ist das Fundament
• ActiveX ist die darauf aufbauende Bauteil-Kultur
• OCX ist die Datei, die man vor Ort findet

8. Wo es eingesetzt wurde

ActiveX/OCX wirken durch die starke Browser-Erinnerung leicht wie alte Web-Technologie. Tatsächlich wurden sie aber wesentlich breiter eingesetzt.

Konkret an Orten wie diesen.

• Desktop-Anwendungen
  • VB6
  • MFC/C++
  • Access-Formulare
  • rund um Office/VBA
• Browser / interne Webanwendungen
  • in den Internet Explorer eingebettete Viewer
  • Signatur-Bauteile
  • Bauteile für Dateiübertragung
  • Bauteile für die Anbindung von Peripheriegeräten
• Bestehende .NET-Anwendungen
  • bestehende ActiveX-Steuerelemente, aus WinForms heraus verpackt genutzt
  • Fälle, in denen bestehende COM-Bestände als UI-Bauteile weiter am Leben gehalten werden

Auch hier landet man am Ende wieder bei dem Punkt, dass ActiveX nicht auf das Internet beschränkt ist. Es wirkt nur deshalb wie eine Web-Technologie, weil es durch den IE so auffällig wurde; in der Praxis passt es besser, es als eingebettete Bauteil-Technologie von Windows zu sehen.

9. Warum es leicht verwechselt wird

9.1. Unterschiedliche Sprachebenen tauchen im selben Gespräch auf

• COM ist eine Frage des Fundaments
• ActiveX ist eine Frage des Bauteil-Kontexts
• OCX ist eine Frage der Datei

Obwohl die Ebenen von vornherein unterschiedlich sind, tauchen sie in der Praxis am selben Ort gleichzeitig auf, sodass das Gespräch leicht durcheinandergerät.

9.2. Der Begriff ActiveX ist etwas weit gefasst

COM hat eine vergleichsweise feste Bedeutung. ActiveX dagegen wird sowohl historisch als auch in der Praxis etwas breiter verwendet.

Je nach Person kann gemeint sein:

• das Steuerelement selbst
• die .ocx-Datei
• ein altes, im IE laufendes Bauteil
• COM-basierte eingebettete Bauteile im Allgemeinen

Welches davon gemeint ist, geht auseinander. An diesem Punkt läuft das Gespräch bereits nicht mehr zusammen.

9.3. Sobald man .ocx sieht, möchte man alles ActiveX nennen

Dieser Impuls ist verständlich. Im Alltag funktioniert das meist auch.

Bei Migration oder Recherche muss man aber getrennt betrachten,

• ob es ein UI-Bauteil ist
• in welchem Host es läuft
• ob eine Registrierung nötig ist
• wie es um 32 Bit/64 Bit steht
• ob eine Browser-Abhängigkeit besteht

sonst stolpert man später garantiert darüber.

10. Wie man es in der heutigen Praxis einordnen sollte

Zunächst: Nur weil man COM/ActiveX/OCX findet, muss man es nicht sofort komplett verwerfen. Alles mit derselben Gelassenheit zu behandeln, ist aber ebenfalls gefährlich.

Browserseitige ActiveX-Abhängigkeit

Hier ist es sicherer, bevorzugt streng hinzusehen.

• Sie gehört nicht zum Mainstream der modernen Browser-Entwicklung
• Im Kompatibilitätsbetrieb kommt der IE-Modus zur Sprache, aber der ist eher als Brücke für die Abwärtskompatibilität zu sehen
• Ihn als Grundlage für Neues zu wählen, lässt sich kaum empfehlen

Für die Einschätzung braucht man auch eine Zeitachse. Die IE11-Desktop-Anwendung ist bereits ausgemustert; der verbleibende Boden ist der IE-Modus von Microsoft Edge. Zu diesem IE-Modus hat Microsoft die Linie ausgegeben, ihn mindestens bis 2029 zu unterstützen und eine Abschaffung ein Jahr vorher anzukündigen. Das Jahr 2029 ist also keine „Frist, bis zu der man es liegen lassen darf“, sondern ein Termin, auf den man rückwärts rechnen sollte, um bis dahin fertig abgelöst zu haben. Das konkrete Vorgehen beim Ablösen ist gesondert im „Leitfaden zum Ausstieg aus der Abhängigkeit vom IE-Modus“ beschrieben.

Bei webseitigem ActiveX ist es realistischer, sich zu fragen, wo man es ablöst, statt wie man es am Leben erhält.

Desktopseitige ActiveX-/OCX-Abhängigkeit

Hier lässt sich pragmatischer entscheiden.

• Es läuft stabil innerhalb eines bestehenden Hosts
• Der Verteilungskreis ist begrenzt
• Es gibt eine Wartungsperspektive, ob durch den Hersteller oder im eigenen Haus
• Registrierung, abhängige DLLs und die Bitness-Annahmen sind bekannt

Sind diese Bedingungen erfüllt, ist die Entscheidung, es zu behalten, ganz normal.

Andererseits gilt: Wenn

• man eine 32-Bit-OCX unverändert in einen 64-Bit-Prozess laden möchte
• man nur das Umfeld auf .NET umstellen möchte
• Verteilung und Registrierung jedes Mal scheitern
• eine Browser-Abhängigkeit bestehen bleibt

ist es sicherer, Behalten / Kapseln / Ersetzen getrennt zu betrachten.

In der heutigen Praxis geht es nicht darum, ob ActiveX deshalb schlecht ist, sondern darum, wo man die Grenze zieht. Sieht man es weniger als alte Technologie und mehr als Verbindungsstelle eines bestehenden Systems, lässt es sich leichter handhaben.

11. Häufige Missverständnisse

Missverständnis 1: COM = ActiveX

Falsch. COM ist das Fundament, ActiveX ist der darauf aufbauende Steuerelement-Kontext.

Missverständnis 2: ActiveX = Internet Explorer

Falsch. Dass ActiveX durch den IE bekannt wurde, stimmt, aber ActiveX ist nicht browserspezifisch.

Missverständnis 3: ActiveX = OCX

In der Praxis werden beide Begriffe sehr ähnlich verwendet, streng genommen unterscheiden sie sich aber. ActiveX betrifft den Kontext und das Bauteil, OCX ist die physische Form, der man als Dateiendung begegnet.

Missverständnis 4: OCX ist doch nur eine DLL, oder?

Grob gesagt liegt das nahe, bei der Recherche sollte man das aber nicht grob nehmen. An einer .dll allein lässt sich die Rolle nicht ablesen, eine .ocx riecht dagegen stark nach einem Steuerelement.

Missverständnis 5: COM ist eine tote Technologie

Zumindest in der Windows-Welt ist diese Aussage zu grob. Sie ist nur von der großen Bühne abgetreten und taucht im Design- und Interop-Kontext bis heute auf.

12. Checkpoints für die Recherche

Findet man COM/ActiveX/OCX, hilft es, der Reihe nach diese Punkte zu prüfen, um nicht die Orientierung zu verlieren.

1. Um welches Bauteil handelt es sich?
   • Ein UI-Steuerelement?
   • Ein Viewer?
   • Gerätekopplung?
   • Office-/Access-Integration?
2. Wo läuft es?
   • Access/VBA?
   • VB6/MFC?
   • WinForms?
   • IE/IE-Modus?
3. Welche Datei und welche Bezeichner gibt es?
   • .ocx/.dll/.exe
   • ProgID
   • CLSID
   • Typbibliothek
4. Wie sind Registrierung und Verteilung geregelt?
   • Ist regsvr32 erforderlich?
   • Gibt es abhängige DLLs?
   • Sind Administratorrechte nötig?
5. Stimmt die Bitness?
   • 32 Bit?
   • 64 Bit?
   • Muss es im selben Prozess laufen?
6. Wie soll damit künftig umgegangen werden?
   • So belassen?
   • Eine Grenze ziehen und kapseln?
   • Ersetzen?

12.1. Womit man das recherchiert

Die sechs Punkte oben sagen, „worauf man achtet“; ergänzend sei aufgeführt, „wo man dafür hinschaut“. Ohne das bleibt man auch mit Checkliste schon beim ersten Schritt stecken.

Ohne diese Punkte anzusehen mit Hier ist ActiveX, also implementieren wir alles neu loszulegen, tappt man sauber in die alten Fallen. Es ist sicherer, zuerst die sechs Punkte oben und die passenden Werkzeuge abzuarbeiten und danach in Kapitel 10 zwischen „Behalten / Kapseln / Ersetzen“ zu entscheiden.

13. Zusammenfassung

Den Unterschied zwischen COM/ActiveX/OCX am gröbsten, aber praktisch nützlichsten Satz zusammengefasst:

• COM ist das Fundament
• ActiveX ist der Kontext COM-basierter, eingebetteter Bauteile
• OCX ist die Datei, die man bei ActiveX-Steuerelementen häufig sieht

Kann man diese drei auseinanderhalten, wird deutlich klarer,

• ob es sich um eine bloße .ocx handelt
• ob es ein COM-weites Problem ist
• ob es browserabhängiges ActiveX ist
• ob es ein Bauteil ist, das auf dem Desktop bleiben kann

Legacy-Technologie ist nicht deshalb schwierig, weil die Namen alt sind, sondern weil Fundament, Bauteil und Datei im selben Gespräch auftauchen. Wird die Struktur aber sichtbar, entpuppt sich das Problem als überraschend handhabbar.

14. Quellen

• Was ist COM? – Warum das Design von Windows COM auch heute noch schön ist
• ActiveX / OCX heute behandeln - Entscheidungstabelle: Behalten, Kapseln, Ersetzen
• Component Object Model (COM) - Microsoft Learn
• ActiveX-Steuerelemente - Win32-Apps - Microsoft Learn
• ActiveX Controls - MFC - Microsoft Learn
• ActiveX Control - Access VBA - Microsoft Learn
• Was ist der Internet Explorer (IE)-Modus? - Microsoft Learn
• Häufig gestellte Fragen zum Lebenszyklus von IE und Edge - Microsoft Learn (Richtlinie, den IE-Modus mindestens bis 2029 zu unterstützen)
• regsvr32 - Windows-Befehle - Microsoft Learn
• CLSID-Schlüssel - Win32-Apps - Microsoft Learn
• Registrierungs-Umleitung - Win32-Apps - Microsoft Learn
• Verwenden von DevTools im Internet Explorer-Modus (IE-Modus) - Microsoft Learn

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Was ist eine OCX-Datei?

OCX ist eine Dateiendung, die häufig für die Implementierung von ActiveX-Steuerelementen verwendet wird. Finden Sie in der Windows-Praxis eine .ocx, sollten Sie zunächst ein eingebettetes, steuerelementartiges COM-Bauteil vermuten. Sie taucht häufig als Auslieferung eines Hersteller-SDKs, in alten VB6-/Access-/MFC-Projekten, als Registrierungsziel in einem Installationsprogramm oder als Bauteil auf, das regsvr32 benötigt. Wenn Sie sich merken, dass OCX ein Dateiformat und kein Konzept an sich ist, verwirrt das weniger.

Was ist der Unterschied zwischen COM und ActiveX?

COM ist der binäre Vertrag, über den Komponenten unter Windows miteinander kommunizieren – also das Fundament. ActiveX ist ein auf COM aufbauendes, wiederverwendbares Softwarebauteil und bezeichnet vor allem den Kontext von Steuerelementen, die in einen Host oder Container eingebettet werden. Eine hilfreiche Faustregel: „COM = Mechanismus, ActiveX = Bauteil-Kontext, OCX = Datei.“ Das Fundament von ActiveX ist COM, aber ActiveX ist nicht COM selbst.

Ist ActiveX eine reine Internet-Explorer-Technologie?

Nein. Dass ActiveX durch den IE bekannt wurde, stimmt zwar, aber ActiveX-Steuerelemente sind eine Bauteil-Technologie, die auch auf der Windows-Anwendungsseite lange verwendet wurde – in Access-Formularen, VB6-Anwendungen, MFC-Containern, rund um Office/VBA und als COM-Wrapper aus WinForms heraus. Es passt in der Praxis besser, ActiveX nicht als reine Browser-Technologie, sondern als eingebettete Bauteil-Technologie von Windows zu betrachten. Bei der browserseitigen ActiveX-Abhängigkeit ist es heute realistischer, sich zu fragen, wo man sie ablöst, statt wie man sie am Leben erhält.

Wie unterscheiden sich OCX und DLL?

.ocx ist eine Dateiendung, die recht deutlich auf ein ActiveX-Steuerelement hindeutet, während .dll eine gewöhnliche Bibliothek, ein COM-Server oder eine abhängige DLL rund um ActiveX sein kann. In der Praxis ist es üblich, dass vendorcontrol.ocx die Hauptrolle spielt und DLLs wie vendorhelper.dll unterstützend zur Seite stehen. Fragt man, ob OCX eine Art DLL ist, liegt das gefühlt nahe – bei Recherche und Migration ist es aber sicherer, die Rollen getrennt zu betrachten.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.