What Are COM / ActiveX / OCX? - The Differences and Relationships Explained

The three words COM / ActiveX / OCX almost always show up together in Windows legacy projects.

• A vendor sends you an .ocx file
• A mysterious component sits on an Access or VB6 form
• Someone says “this is COM,” immediately followed by “it’s ActiveX”
• And then regsvr32, 32-bit / 64-bit, and IE mode all come rushing in at once

At this point, the conversation usually stops lining up. The terms are close to each other, and historically they overlap heavily. Conversely, once you can keep them apart, investigation, migration, and explanation all become dramatically easier.

flowchart TB
    accTitle: Why the conversation stops lining up
    accDescr: When the close-sounding terms COM, ActiveX and OCX all arrive at once on the same project, the conversation stops lining up. Separating which one is the foundation, which is the component and which is the file makes investigation, migration and explanation much easier.
    mix["Three terms arrive at once"] --> lost["The conversation stops lining up"]
    split["Separate foundation, component and file"] --> clear["Investigation, migration and explanation get easier"]

Figure 1: This article has one goal: separating which is the foundation, which is the component, and which is the file.

In this article, we sort out what COM is, what ActiveX is, and what OCX is, in an order that makes the differences and relationships visible. In particular, we make it clear which is the foundation, which is the component, and which is the file.

Table of Contents

1. The Conclusion First (In One Line)
2. What This Article Means by COM / ActiveX / OCX
3. The One-Page Overview
   • 3.1. Relationship Diagram
   • 3.2. The Shortest Glossary
4. What Is COM?
   • 4.1. In One Sentence
   • 4.2. What Matters in COM
   • 4.3. One-Line Notes on the Terminology
5. What Is ActiveX?
   • 5.1. In One Sentence
   • 5.2. ActiveX Is Not Browser-Only
6. What Is OCX?
   • 6.1. In One Sentence
   • 6.2. How It Differs from a .dll
7. The Differences in a Table
8. Where They Were Used
9. Why They Are So Easily Confused
10. How to Think About Them in Practice Today
11. Common Misconceptions
12. Checkpoints When Investigating
13. Summary
14. References

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (18 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

1. The Conclusion First (In One Line)

Here is the rough-but-useful version up front.

• COM is the foundation: the binary contract that lets components talk to each other on Windows
• ActiveX is the COM-based component context: it most often appears as controls embedded into a host
• OCX is the implementation file you commonly see for ActiveX controls: you encounter it as a file extension
• In other words, COM = the mechanism, ActiveX = the component context, OCX = the file is a framing that keeps things clear
• The memory of ActiveX = that dangerous old browser thing is half right and half incomplete. ActiveX is not browser-only
• OCX = ActiveX is often used almost interchangeably, but strictly speaking that mixes a concept with a file extension
• It is not a technology you would build new development around today, but you still encounter it in existing Windows apps, Office, Access, device SDKs, and internal web systems

It all starts with keeping these three questions apart.

1. Is this a question about COM?
2. Is this a question about an ActiveX control?
3. Or is someone simply calling it that because they saw an .ocx file?

Once you can tell, much of the fog lifts.

flowchart TB
    accTitle: The three questions to separate first
    accDescr: Start by separating whether the topic at hand is COM as a mechanism, an ActiveX control as a component, or simply an ocx file that someone is naming after what they saw.
    q{"What are we actually talking about"}
    q --> a["COM = the mechanism"]
    q --> b["ActiveX = the component context"]
    q --> c["OCX = the file"]

Figure 2: When in doubt, return to these three choices. COM is the mechanism, ActiveX is the component context, OCX is the file.

2. What This Article Means by COM / ActiveX / OCX

In practice, these three terms often live together rather sloppily. So this article first pins down the meanings.

• COM: the Windows component model itself. The foundation of interfaces, GUIDs, registration, and invocation
• ActiveX: embeddable controls built on COM, and the context in which they are used. In practice it usually means ActiveX controls
• OCX: the file extension commonly seen for ActiveX control implementations. .ocx

One small caveat: historically, the word ActiveX was used somewhat more broadly for a time. But the places where ActiveX causes trouble in today’s practice almost all revolve around controls, embedding, hosts, browsers, and registration.

So this article also proceeds with ActiveX as the ActiveX control side of the story as the baseline.

flowchart TB
    accTitle: The breadth of the word ActiveX and this article's focus
    accDescr: Historically the word ActiveX was used more broadly, but what causes trouble in practice today is controls, embedding, hosts, browsers and registration, so this article narrows its focus to the ActiveX control side.
    word["The word ActiveX"] --> wide["Historically a broader meaning too"]
    word --> now["Today the trouble sits around controls"]
    now --> focus["This article stays on the control side"]
    now -.-> items["Embedding, hosts, browsers, registration"]

Figure 3: Acknowledge the historical breadth of the word, then fix the focus on the control side, which is where practice actually hurts.

3. The One-Page Overview

3.1. Relationship Diagram

The fastest way in is to see the whole picture on one page. If diagrams do not render in your environment, the bullet list right below the diagram carries the same content, so read that instead.

flowchart LR
    COM["COM<br/>Foundation of binary contracts"] --> OLE["OLE / Automation<br/>Embedding and automation mechanisms"]
    OLE --> AX["ActiveX<br/>COM-based control context"]
    AX --> CTRL["ActiveX control"]
    CTRL --> OCX["OCX (.ocx)<br/>Common implementation file form"]

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

Figure 4: A relationship diagram showing how OLE / Automation, ActiveX, and OCX stack on top of COM, and how a host carries the control.

The important point here is that COM and ActiveX are not the same word.

• COM is the foundation
• OLE / Automation are the mechanisms for embedding and automation
• ActiveX appears as the control context used on top of them
• OCX is the file you commonly see for those control implementations

So if someone asks Is ActiveX the same as COM?, the answer is: the foundation is COM, but ActiveX is not COM itself.

3.2. The Shortest Glossary

If you only memorize the shortest version, this is enough.

• COM is the mechanism
• ActiveX is the component context
• OCX is the file

4. What Is COM?

4.1. In One Sentence

COM stands for Component Object Model: the binary contract that lets components talk to each other on Windows.

By binary contract, we mean an interface whose promises hold even in compiled form, independent of source-code arrangements or language specifics. A component written in C++ can be used from a different language or a different application precisely because this contract exists.

In practical terms, COM is less a way to distribute handy libraries and more a mechanism that hides the implementation and connects things by contract alone.

These are typical hallmarks of COM (each term gets a one-line explanation in 4.3).

• Reference counting via IUnknown
• Interface discovery via QueryInterface
• GUID-based identification via IID and CLSID
• In-process use via DLLs
• Out-of-process use via EXEs

In short, COM is the foundation of the componentization culture on Windows.

flowchart TB
    accTitle: The idea of a binary contract
    accDescr: COM connects components through a binary contract, a promise that holds even after compilation rather than depending on source code or language specifics, which is why a component written in C++ can be used from another language or another application.
    part["Component (implementation hidden)"] --> contract["Binary contract (the published promise)"]
    contract --> user["A different language or a different app"]
    contract -.-> note["The promise still holds after compilation"]

Figure 5: The core of COM is hiding the implementation and connecting through the contract alone. That is what lets components cross language boundaries.

4.2. What Matters in COM

If you stick to the essentials, what matters in COM is the following.

• Interface-centric design
  • You decide what to expose before how to implement it
• Identification by GUID
  • Classes and interfaces are identified uniquely
• Separation of host and implementation
  • Callers do not need to know the internal implementation
• Crossing process boundaries
  • Components can be used not just in-process but in other processes as well

This is what keeps COM from being just an old technology. From remarkably early on, it had a solid grip on contract-based, reusable design.

flowchart TB
    accTitle: The four pillars that matter in COM
    accDescr: Interface-centric design, unique identification by GUID, separation of host and implementation, and the ability to cross process boundaries are the four things that make COM a contract-based design for reuse.
    com["COM basics"] --> p1["Interface-centric"]
    com --> p2["Identification by GUID"]
    com --> p3["Separation of host and implementation"]
    com --> p4["Can cross process boundaries"]

Figure 6: The four pillars holding up COM. From remarkably early on it had contract-based, reusable design.

4.3. One-Line Notes on the Terminology

In COM discussions, the following words get thrown at you with no explanation. As an entry point to the concepts, here is one line each. If you want to go further into what makes the design interesting, see What Is COM? - Why the Design of Windows COM Is Still Beautiful Today.

This article only goes as far as sorting out the concepts, so it does not dig into the details of each item. When you do need the implementation side, using the words in this table verbatim as search terms is a good way to get your bearings.

flowchart TB
    accTitle: The basic behavior built on IUnknown
    accDescr: IUnknown, the base of every COM interface, has a basic behavior: QueryInterface asks for another interface, AddRef and Release move the reference count up and down, and the component is freed the moment the count reaches zero.
    iu["IUnknown (the base of everything)"] --> qi["Ask with QueryInterface"]
    qi --> got["If it has it, a pointer comes back"]
    iu --> rc["AddRef and Release manage the count"]
    rc --> zero["At zero the component is freed"]

Figure 7: The three methods of IUnknown, at the center of the glossary, split into two jobs: asking and counting.

5. What Is ActiveX?

5.1. In One Sentence

ActiveX is best understood as reusable software components built on COM - in particular, controls embedded into hosts or containers.

When people say ActiveX in practice, they are very likely talking about ActiveX controls: things like buttons, grids, charts, calendars, viewers, and device-integration components.

ActiveX is less of a giant technology standing proudly on its own and more of a component that works while embedded inside some host - framing it that way rarely leads you astray.

flowchart TB
    accTitle: A component that works embedded in a host
    accDescr: When people say ActiveX in practice they are very likely talking about ActiveX controls, meaning parts such as buttons, grids, charts, viewers and device-integration components that work embedded in a host or container.
    host["Host / container"] --> ctrl["ActiveX control"]
    ctrl --> ex1["Grids and calendars"]
    ctrl --> ex2["Viewers and device-integration parts"]
    ctrl -.-> note["Not a giant technology standing on its own"]

Figure 8: Treat ActiveX as a component that works while embedded, and you rarely go wrong.

5.2. ActiveX Is Not Browser-Only

The impression that ActiveX = that Internet Explorer thing is very strong. It is not wrong - but it is not the whole story.

Here are the places ActiveX controls have been used:

• Access forms
• VB6 (Visual Basic 6.0) applications
• MFC (Microsoft Foundation Class library) containers
• Office / VBA surroundings
• Existing ActiveX controls wrapped for use from WinForms
• Internet Explorer and its compatibility-mode operations

In other words, ActiveX is not a browser-only technology - it has long been used on the Windows application side as well.

Miss this, and you end up treating ActiveX found in an internal web system and ActiveX embedded in an Access form as different things. In reality, both are close relatives on the COM side.

flowchart TB
    accTitle: Where ActiveX controls have been used
    accDescr: Access forms, VB6 applications, MFC containers, Office and VBA surroundings, COM wrappers from WinForms, and Internet Explorer: ActiveX is not browser-only and has long been used on the Windows application side.
    ax["ActiveX control"] --> d["Access, VB6 and MFC"]
    ax --> o["Office and VBA surroundings"]
    ax --> w["COM wrappers from WinForms"]
    ax --> ie["The Internet Explorer family"]
    ie -.-> myth["Only this part became famous"]

Figure 9: IE is merely where it stood out. Most of the places it was used sit on the Windows application side.

6. What Is OCX?

6.1. In One Sentence

OCX is the file extension commonly used for ActiveX control implementations. If you find an .ocx in a Windows environment, your first suspicion should be an embeddable, control-style COM component.

The typical places it shows up:

• Vendor SDK distributions
• Old VB6 / Access / MFC projects
• Files an installer needs to register
• Components that require regsvr32

The thing to keep in mind is that OCX is a file format, not the concept itself. So if you want a rough answer to what is OCX, it is: the file you most often encounter as the physical form of an ActiveX control.

6.2. How It Differs from a .dll

This is another common point of confusion.

• An .ocx strongly suggests an ActiveX control
• A .dll might be an ordinary library, a COM server, or a dependency DLL around an ActiveX component

Seeing an .ocx lets you guess it is ActiveX-adjacent; seeing a .dll alone tells you nothing yet about what it is.

A common pattern in the field is a lineup like

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

where the OCX is the lead and the DLLs play supporting roles.

So if asked is an OCX a kind of DLL? - intuitively, yes, close - but during an investigation it is safer to look at the roles separately.

flowchart TB
    accTitle: How much the extension tells you
    accDescr: A .ocx strongly suggests an ActiveX control, while a .dll could still be an ordinary library, a COM server or a dependency, so you cannot tell yet. In practice the OCX often leads while DLLs play supporting roles.
    q{"Which extension is it"}
    q -->|".ocx"| ax["Almost certainly ActiveX-adjacent"]
    q -->|".dll"| unk["Still unknown"]
    unk --> roles["Library, COM server or dependency"]
    ax -.-> pair["OCX in the lead, DLLs in support"]

Figure 10: A .ocx lets you make an educated guess; a .dll tells you nothing until you investigate its role.

7. The Differences in a Table

If you remember anything from this table, start here.

• COM is the groundwork
• ActiveX is the component culture built on top of it
• OCX is the file you pick up in the field

8. Where They Were Used

Because the browser memories are so vivid, ActiveX / OCX tend to look like old web technology. In reality, they were used far more broadly.

Concretely, in places like these:

• Desktop applications
  • VB6
  • MFC / C++
  • Access forms
  • Office / VBA surroundings
• Browsers / internal web systems
  • Viewers embedded in Internet Explorer
  • Signing components
  • File transfer components
  • Peripheral-device integration components
• Existing .NET applications
  • Existing ActiveX controls wrapped for use from WinForms
  • Existing COM assets kept alive as UI components

Which brings us back, once again, to the point that ActiveX is not internet-only. It just looks like a web technology because it was so conspicuous in IE; in substance, it is more accurate - and more useful in practice - to see it as a Windows embedding-component technology.

flowchart TB
    accTitle: The gap between perception and reality
    accDescr: Because ActiveX stood out so much in IE it tends to look like old web technology, but it was actually used widely across desktop applications, internal web systems and existing .NET applications, and in substance it is a Windows embedding-component technology.
    look["Memory of standing out in IE"] --> web["Looks like old web technology"]
    real["Where it was actually used"] --> r1["Desktop applications"]
    real --> r2["Browsers and internal web systems"]
    real --> r3["Existing .NET applications"]
    r1 -.-> truth["In substance a Windows embedding-component technology"]

Figure 11: The gap between looking like old web technology and actually being a Windows embedding-component technology.

9. Why They Are So Easily Confused

9.1. Different layers of language, same conversation

• COM is a question of the foundation
• ActiveX is a question of the component context
• OCX is a question of the file

They sit at different layers in the first place, yet in practice they all show up on the same project at the same time - so conversations get tangled easily.

9.2. The word ActiveX is a bit broad

COM has a relatively fixed meaning. ActiveX, on the other hand, is used somewhat broadly, both historically and in practice.

Depending on the person, it can refer to

• the control itself
• the .ocx file
• an old component that runs in IE
• COM-based embeddable components in general

and those references diverge. At that point, the conversation has already stopped lining up.

9.3. The moment you see an .ocx, you want to call everything ActiveX

We understand the impulse. And for everyday conversation, it usually works.

But for migration or investigation, unless you separately check

• whether it is a UI component
• which host it runs in
• whether it needs registration
• what the 32-bit / 64-bit situation is
• whether there is a browser dependency

you will trip up badly later on.

flowchart TB
    accTitle: Three reasons the confusion happens
    accDescr: Three things cause the confusion: topics from different layers appearing in the same conversation, the word ActiveX being somewhat broad, and the urge to call everything ActiveX the moment an ocx file shows up.
    r1["Different layers in one conversation"] --> mixup["The conversation gets tangled"]
    r2["The word ActiveX is broad"] --> mixup
    r3["Seeing an ocx and naming everything that"] --> mixup
    mixup -.-> risk["Migration and investigation trip up"]

Figure 12: The real nature of the confusion is that foundation, component, and file - three different layers - turn up on the same project at once.

10. How to Think About Them in Practice Today

First: finding COM / ActiveX / OCX does not mean you must immediately reject everything. But treating all of it with the same level of urgency is also dangerous.

Browser-side ActiveX dependencies

These are safer to scrutinize harshly, and first.

• They are not part of the mainstream of modern browser development
• IE mode comes up in compatibility-operations contexts, but it is best seen as a bridge for backward compatibility
• Adopting it as a premise for anything new is hard to recommend

The decision also needs a timeline. The IE11 desktop application has already been retired, and the footing that remains today is IE mode in Microsoft Edge. For that IE mode, Microsoft has stated a policy of supporting it at least through 2029, with one year’s notice before any retirement. In other words, 2029 is not a deadline you can leave things alone until; it is the date to finish peeling off by, working backwards from it. The peeling-off procedure itself is covered separately in A Guide to Breaking Free from IE Mode Dependence.

For web-side ActiveX, it is more realistic to think in terms of “where do we start peeling it off” rather than “how do we keep it alive.”

flowchart TB
    accTitle: The timeline for browser-side ActiveX
    accDescr: The IE11 desktop application has been retired and the remaining footing is IE mode in Edge, which Microsoft has said it will support at least through 2029 with one year of notice before any retirement. 2029 is not a date to leave things alone until but the date to finish peeling off by, working backwards.
    ie11["IE11 desktop is already retired"] --> iem["The remaining footing is IE mode in Edge"]
    iem --> y2029["Supported at least through 2029"]
    y2029 --> plan["Work backwards from the finish-peeling-off date"]
    y2029 -.-> notice["Policy of one year notice before retirement"]

Figure 13: 2029 is a deadline, not breathing room. On the browser side, think in terms of where to start peeling off.

Desktop-side ActiveX / OCX dependencies

These can be judged a bit more pragmatically.

• It runs stably inside an existing host
• Distribution targets are limited
• There is a maintenance outlook, whether vendor or in-house
• The registration, dependency DLLs, and bitness assumptions are understood

If those conditions hold, keeping it is a perfectly normal decision.

On the other hand, if

• you want to load a 32-bit OCX directly into a 64-bit process
• you want to move only the surrounding code to .NET
• distribution and registration trip you up every time
• a browser dependency remains

then it is safer to consider keep / wrap / replace as distinct options.

What today’s practice actually asks is not whether ActiveX is therefore bad, but where to draw the boundary. Seen less as old technology and more as the seam of an existing system, it becomes much easier to handle.

flowchart TB
    accTitle: How the desktop-side decision splits
    accDescr: If stable operation, limited distribution, a maintenance outlook and understood assumptions all line up, keeping the component is a perfectly normal decision. If bitness conflicts, partial .NET migration, distribution failures or browser dependencies are in play, treat keep, wrap and replace as separate options.
    q{"Are the conditions met"}
    q -->|"Stable operation and understood assumptions"| keep["Keeping it is a normal decision"]
    q -->|"There are sticking points"| split["Separate keep, wrap and replace"]
    split -.-> view["As a seam, where to draw the boundary"]

Figure 14: On the desktop side, judge case by case. The question is not good versus bad but where the boundary sits.

11. Common Misconceptions

Misconception 1: COM = ActiveX

No. COM is the foundation; ActiveX is the control context used on top of it.

Misconception 2: ActiveX = Internet Explorer

No. It is true that IE made it famous, but ActiveX is not browser-only.

Misconception 3: ActiveX = OCX

In practice they are used in very similar senses, but strictly speaking they differ. ActiveX is about the context and the components; OCX is the physical form you encounter as a file extension.

Misconception 4: An OCX is just a DLL, right?

Roughly speaking, close - but do not be rough about it during an investigation. A .dll alone tells you nothing about its role, whereas an .ocx smells strongly of a control.

Misconception 5: COM is a dead technology

In the Windows world at least, that is putting it too crudely. It has merely stepped back from the spotlight; it still appears in design and interoperability contexts today.

flowchart TB
    accTitle: How to correct the common misconceptions
    accDescr: COM is not ActiveX itself but the foundation, ActiveX is not IE-only, ActiveX and OCX differ as concept versus file, and COM is not a dead technology. This sums up how to correct each misconception.
    m1["COM = ActiveX ?"] --> a1["COM is the foundation, a separate thing"]
    m2["ActiveX = IE only ?"] --> a2["Still active on the desktop"]
    m3["ActiveX = OCX ?"] --> a3["A concept versus a file"]
    m4["COM is dead ?"] --> a4["Still shows up in interoperability"]

Figure 15: All five misconceptions come from the same place: mixing up the layers.

12. Checkpoints When Investigating

When you find COM / ActiveX / OCX, walking through these in order keeps you from getting lost.

1. What kind of component is it?
   • A UI control?
   • A viewer?
   • Device integration?
   • Office / Access integration?
2. Where does it run?
   • Access / VBA?
   • VB6 / MFC?
   • WinForms?
   • IE / IE mode?
3. What are the files and identifiers?
   • .ocx / .dll / .exe
   • ProgID
   • CLSID
   • Type Library
4. How are registration and distribution handled?
   • Is regsvr32 required?
   • Are there dependency DLLs?
   • Are administrator rights required?
5. Does the bitness match?
   • 32-bit?
   • 64-bit?
   • Does it need to run in the same process?
6. How will it be handled going forward?
   • Keep it as is?
   • Draw a boundary and wrap it?
   • Replace it?

12.1. What to Use to Investigate

The six points above cover what to look at, so here is where to open as well. Without this, a checklist stalls at the very first step.

Charge ahead with there's ActiveX here, so we'll reimplement everything from scratch without looking at any of this, and you will step neatly into every classic trap. It is safer to fill in the six points above and the matching tools first, and only then decide on keep / wrap / replace from chapter 10.

flowchart TB
    accTitle: The order of investigation
    accDescr: Check in order what kind of component it is, where it runs, what the files and identifiers are, how registration and distribution are handled, and whether the bitness matches, then decide between keep, wrap and replace.
    s1["See what kind of component it is"] --> s2["See where it runs"]
    s2 --> s3["Identify the files and identifiers"]
    s3 --> s4["Check registration and distribution"]
    s4 --> s5["Check the bitness"]
    s5 --> s6["Decide keep, wrap or replace"]

Figure 16: Rather than rushing into a rewrite, fill these in in order and then decide the approach.

13. Summary

The roughest - but most practically useful - way to state the differences between COM / ActiveX / OCX is this.

• COM is the foundation
• ActiveX is the context of COM-based embeddable components
• OCX is the file you commonly see for ActiveX controls

Once you can keep these three apart, it becomes far easier to see

• whether this is merely an .ocx
• whether it is a COM-wide problem
• whether it is browser-dependent ActiveX
• whether it is a component that can stay on the desktop

Legacy technology is not hard because the names are old - it is confusing because the foundation, the components, and the files all show up in the same conversation. But once the structure is visible, it turns out to be a surprisingly manageable problem.

14. References

• What Is COM? - Why the Design of Windows COM Is Still Beautiful Today
• How to Handle ActiveX / OCX Today - A Keep / Wrap / Replace Decision Table
• 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
• IE and Edge lifecycle FAQ - Microsoft Learn (the policy of supporting IE mode at least through 2029)
• regsvr32 - Windows commands - Microsoft Learn
• CLSID key - Win32 apps - Microsoft Learn
• Registry redirector - Win32 apps - Microsoft Learn
• Use DevTools in Internet Explorer mode (IE mode) - Microsoft Learn

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

What is an OCX file?

OCX is the file extension commonly used for ActiveX control implementations. When you find a .ocx in a Windows environment, your first suspicion should be an embeddable, control-style COM component. It usually turns up as part of a vendor SDK distribution, in old VB6 / Access / MFC projects, among the files an installer registers, or as a component that requires regsvr32. Keeping in mind that OCX is a file format rather than the concept itself will save you a lot of confusion.

What is the difference between COM and ActiveX?

COM is the binary contract that lets components talk to each other on Windows - the foundation. ActiveX is a reusable software component built on COM, and it most often refers to the context of controls embedded into a host or container. Thinking of it as COM = the mechanism, ActiveX = the component context, OCX = the file gives you a clear view. ActiveX rests on COM, but ActiveX is not COM itself.

Is ActiveX a technology exclusive to Internet Explorer?

No. It is true that IE made it famous, but ActiveX controls have long been used on the Windows application side as well: on Access forms, in VB6 applications, in MFC containers, around Office and VBA, and through COM wrappers from WinForms. In practice it fits better to see it as a Windows embedding-component technology rather than a browser-only one. That said, for browser-side ActiveX dependencies it is more realistic today to ask where to start peeling them off than how to keep them alive.

How does an OCX differ from a DLL?

A .ocx strongly suggests an ActiveX control, whereas a .dll might be an ordinary library, a COM server, or a dependency DLL around an ActiveX component. A common field pattern is vendorcontrol.ocx in the lead with DLLs such as vendorhelper.dll playing supporting roles. If you ask whether an OCX is a kind of DLL, intuitively that is close - but when investigating or migrating, it is safer to keep the roles separate.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.