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 hits mud. 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.

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
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

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.

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 ≈ the ActiveX control side of the story as the baseline.

3. The One-Page Overview

3.1. Relationship Diagram

The fastest way in is to see the whole picture on one page.

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

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:

• 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.

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.

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.

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 applications
• MFC 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 very much COM-flavored relatives.

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.

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.

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 at the same site 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 later — guaranteed.

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 temperature 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

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.”

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 joint surface of an existing system, it becomes much easier to handle.

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 don’t 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 center stage; it still appears in design and interoperability contexts today.

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?

Charge ahead with there's ActiveX here, so we'll reimplement everything from scratch without looking at these, and you will step on every classic trap in the book. There is no need to practice reflexology in a minefield.

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
• 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
• 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.

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.