COM, ActiveX e OCX — Distinzioni pratiche per chi eredita sistemi Windows

COM, ActiveX, OCX. Questi tre nomi appaiono insieme in quasi tutti i sistemi Windows ereditati, ma usano significati leggermente diversi e spesso vengono fusi.

• “È rotto un .ocx, quindi ripariamo ActiveX”
• “COM non funziona più”
• “Perché non eliminiamo ActiveX e basta?”

Questo tipo di frase è comune, ma se i nomi vengono trattati come intercambiabili, la troubleshooting e la migrazione finiscono per impantanarsi.

In questo articolo ripartiamo dalle basi.

• COM è la tecnologia di base
• ActiveX è il contesto in cui si usano componenti COM embeddabili
• OCX è il file che spesso contiene un controllo ActiveX basato su COM

Una volta separati questi tre, diventa molto più facile vedere se un problema è specifico di un .ocx, di COM in generale, o di ActiveX in un browser.

1. La conclusione prima di tutto

Per chi non vuole leggere tutto.

• COM = tecnologia di componenti binari di base su Windows
• ActiveX = componenti COM che possono essere embeddati in app e pagine web, spesso controlli UI
• OCX = un’estensione di file tipica per le ActiveX controls
• Quindi: OCX ⊂ ActiveX ⊂ COM — come file, come concetto, come tecnologia

Inoltre:

• La decisione “tenere / wrappare / sostituire” dipende non dal nome, ma da dove gira (browser vs desktop, 32-bit vs 64-bit, network vs locale) e da chi possiede il sorgente
• Un controllo OCX non è pericoloso di per sé: diventa problematico quando viene caricato in contesti non attendibili come il web
• In un’app desktop attendibile, l’OCX continua a funzionare; il problema è più supporto a lungo termine che sicurezza immediata
• La parola ActiveX oggi spaventa più di quanto dovrebbe, perché viene associata a IE; ma molti componenti COM embeddabili in app desktop vengono ancora chiamati ActiveX

2. COM come fondamento

COM (Component Object Model) è la tecnologia di base di Windows per costruire componenti binari che possono essere chiamati tra processi e linguaggi.

I concetti base sono:

• Interfaccia (IUnknown, QueryInterface)
• Conteggio riferimenti
• Class ID (CLSID) e Interface ID (IID)
• Registrazione nel registry
• In-process (DLL) o out-of-process (EXE)
• Apartment (STA / MTA)
• Marshaling per attraversare i confini di thread e processo

flowchart TD
    Client["Client (qualsiasi linguaggio)"] -->|QueryInterface| IUnknown["IUnknown"]
    IUnknown -->|"Ottiene IMyInterface"| Impl["Implementazione COM (DLL/EXE)"]
    Impl -->|"CLSID → percorso file"| Registry["Registry HKCR\\CLSID"]
    Impl --> STA["Apartment STA"]
    Impl --> MTA["Apartment MTA"]
    STA -->|Marshal| MTA
    MTA -->|Marshal| STA

COM non è un linguaggio o un framework. È un modo di separare implementazione e interfaccia. Per questo motivo, componenti COM possono essere scritti in C++, C#, Visual Basic, Delphi e chiamati da molti linguaggi diversi.

La bellezza di COM, da programmatore Windows, sta proprio in questo: definisci un’interfaccia, implementi un oggetto, lo registri, e chiunque può usarlo. La parte dura è che questo stesso potere richiede discipline attorno a riferimenti, marshaling, bitness, registrazione e distruzione.

3. ActiveX: COM reso embeddable

ActiveX è il termine introdotto da Microsoft per i componenti COM che possono essere embedded in altre applicazioni o nelle pagine web.

Il termine è nato nel contesto di Internet Explorer, ma in realtà si applica anche a:

• Controlli UI in Visual Basic 6
• Controlli inseriti in pagine web
• Componenti embeddabili in MFC / WinForms / WPF
• OleControls / OCX in Delphi, C++ Builder e altri ambienti

ActiveX non è una tecnologia separata da COM. È COM con una prospettiva diversa: essere caricato e usato da un contenitore.

flowchart LR
    subgraph "ActiveX come concetto"
    A[Controllo ActiveX] -->|COM| B[Interfacce IUnknown]
    A -->|"Embed in contenitore"| C[App / pagina web]
    end

Quando senti “ActiveX”, pensa a:

• Componente COM
• Che espone interfacce come IDispatch
• Che può essere embedded e instanziato da un contenitore
• Che spesso ha eventi, proprietà e metodi esposti al contenitore

La paura moderna di ActiveX deriva principalmente dal fatto che venivano scaricati ed eseguiti nelle pagine web. Ma un controllo ActiveX dentro una finestra WinForms è concettualmente diverso dal caricarlo da http://sito-non-affidabile.example.

4. OCX: il file

OCX sta per OLE Control eXtension. È semplicemente una DLL COM con estensione .ocx che contiene un controllo ActiveX.

Per la maggior parte delle intenzioni pratiche:

• .ocx è una DLL
• Ha un DllRegisterServer / DllUnregisterServer
• Viene registrata con regsvr32
• Espone uno o più controlli ActiveX identificati da CLSID

flowchart LR
    subgraph "OCX file"
    File["File .ocx"] -->|Estensione per controllo| OCXNode["OCX = DLL COM"]
    OCXNode -->|Contiene| CLSID["1+ CLSID"]
    CLSID -->|"regsvr32 registra"| Registry["HKCR\\CLSID"]
    end

Perché è importante distanziare OCX e ActiveX?

Perché quando qualcuno dice “il problema è ActiveX”, potrebbe in realtà voler dire:

• “un file .ocx manca”
• “non è registrato correttamente”
• “Office 64-bit non può caricare un OCX a 32-bit”
• “un aggiornamento di sicurezza lo ha disabilitato”
• “il browser non supporta più i controlli”

Tutto questo ha a che fare con COM, ma i sintomi sono localizzati nel file, nella registrazione, o nel contenitore.

5. Relazione tra i tre

Visivamente, la relazione è questa.

flowchart TD
    COM["COM (tecnologia base)"] --> ActiveX["ActiveX (contesto: componenti COM embeddabili)"]
    ActiveX --> OCX["OCX (estensione file di un controllo ActiveX)"]

In altre parole:

• Ogni ActiveX è COM
• Ogni OCX è un file ActiveX
• Non ogni componente COM è ActiveX (es. server COM out-of-process, COM librerie semplici)
• Non ogni ActiveX è un .ocx (es. controlli in Java o in altre tecnologie embeddabili, oggi meno comuni)

flowchart LR
    COM["COM"] -->|include| ActiveX["ActiveX"]
    ActiveX -->|spesso| OCX["OCX (.ocx)"]
    COM -->|non sempre| Other["Server COM / librerie COM"]

6. Perché le cose si rompono oggi

6.1. Bitness

Uno dei colpevoli più frequenti nei sistemi Windows ereditati.

Un controllo OCX a 32-bit non può essere caricato in-process da un processo a 64-bit, e viceversa. Office a 64-bit non può caricare OCX a 32-bit. Un’app desktop a 64-bit non può caricare OCX a 32-bit.

flowchart LR
    subgraph "Processo 64-bit"
    P64["Processo x64"] -->|NO| O32["OCX x86"]
    P64 -->|SI| O64["OCX x64"]
    end

Di conseguenza:

• Se hai un OCX a 32-bit, il contenitore deve essere a 32-bit
• O devi trovare / ricompilare il controllo a 64-bit
• Oppure spostare il componente out-of-process con COM / HTTP / altro confine e usare IPC

6.2. Registrazione mancante o corrotta

Un file .ocx deve essere registrato nel registry per essere usato come COM. Quando si copia a mano un file in una cartella, questo non lo registra automaticamente.

flowchart LR
    A[Copia xxx.ocx] --> B{"regsvr32 xxx.ocx eseguito?"}
    B -- No --> C[Le app non trovano il CLSID]
    B -- Si --> D[Le app possono istanziare il controllo]

Nota: per componenti COM costruiti con .NET, non si usa regsvr32 ma RegAsm.exe, come spiegato in dettaglio negli articoli correlati.

6.3. Dipendenze mancanti

Un OCX spesso dipende da altre DLL, dal VC++ Redistributable, da .NET Framework o da altri OCX.

flowchart TD
    OCX["xxx.ocx"] --> A[mscomctl.ocx]
    OCX --> B["VC++ Redistributable"]
    OCX --> C[".NET Framework 4.x"]
    OCX --> D["Altre DLL del vendor"]
    A -->|non presente| E[Errore caricamento]
    B -->|non presente| E
    C -->|non presente| E
    D -->|non presente| E

Strumenti utili per tracciare questo:

• Process Explorer per vedere quali DLL sono caricate
• Process Monitor (Procmon) per tracciare NAME NOT FOUND e PATH NOT FOUND
• dumpbin /DEPENDENTS per elencare le dipendenze statiche di una DLL

6.4. Impostazioni di sicurezza

In Office moderno, i controlli ActiveX sono disabilitati di default. Inoltre, file aperti da condivisioni di rete o da allegati email possono finire in Protected View.

flowchart TD
    A[Apertura file con ActiveX] --> B{Trust Center / Protected View?}
    B -- Bloccato --> C[Barra gialla / non eseguito]
    B -- Consentito --> D[Controllo istanziato]
    D --> E{Bitness / Registrazione / Dipendenze OK?}
    E -- No --> F[Errore]
    E -- Si --> G[Funziona]

Per approfondimenti su questo punto, vedi Perché ActiveX smette di funzionare in Office 2024 / Microsoft 365 e come diagnosticarlo.

6.5. Internet Explorer / contesto web

I controlli ActiveX nel browser sono la ragione storica della fama negativa.

• IE non è più il browser principale
• Edge non supporta i controlli ActiveX legacy (IE mode a parte)
• Caricare controlli binari non attendibili da Internet era un rischio di sicurezza evidente

Quindi se il tuo OCX è usato dentro una pagina web, il problema non è tanto COM o ActiveX in sé, ma il contesto di esecuzione nel browser. Se è usato in IE mode con Enterprise Site List, allora si tratta di configurare correttamente quel percorso.

7. Decisioni pratiche: keep, wrap, replace

Quando erediti un sistema che usa OCX, devi decidere cosa farne.

flowchart TD
    A[Ho un OCX legacy] --> B{Chi possiede il sorgente?}
    B -- Sorgente disponibile --> C{Riscrivibile in breve?}
    B -- Sorgente non disponibile --> D{Bitness / ambiente compatibile?}
    C -- Sì, calcolo semplice --> E[Sostituisci con libreria .NET / C++]
    C -- No, UI complessa --> F[Wrappa o isola]
    D -- Sì, 32-bit locale --> G[Tieni e registra correttamente]
    D -- No, 64-bit necessario --> H[Wrappa con out-of-process COM / gRPC / HTTP]
    F --> H
    H --> I[Progressive migration]

7.1. Keep (tenere)

Quando ha senso.

• Il sistema funziona e non richiede cambiamenti
• L’ambiente è 32-bit e locale
• Il controllo è firmato e attendibile
• La sostituzione costerebbe più del valore ottenuto
• C’è un piano di fine-vita del sistema stesso

Cosa fare nel frattempo.

• Registra correttamente l’OCX nelle immagini di deployment
• Pinna le dipendenze (VC++ runtime, .NET Framework)
• Documenta l’architettura per il prossimo proprietario
• Proteggi il deployment (nessun download da internet, site list controllata)

7.2. Wrap (wrappare / isolare)

Quando ha senso.

• Il controllo è necessario ma deve essere usato in un’app a 64-bit
• Devi isolare il componente per ragioni di sicurezza
• Vuoi progressivamente sostituire parti senza riscrivere tutto

Approcci tipici.

• Out-of-process COM: istanziare l’OCX in un processo separato e comunicare via COM IPC
• Host 32-bit dedicato: un processo helper x86 che espone un’API verso l’app principale x64
• HTTP / gRPC wrapper: incapsula la logica dell’OCX dietro un servizio locale
• UI a più processi: mantieni solo il controllo in una finestra separata

7.3. Replace (sostituire)

Quando ha senso.

• Il controllo esegue solo calcoli e nessuna UI
• Il sorgente esiste ed è ragionevolmente piccolo
• Devi supportare anche browser moderni o ambienti cloud
• Hai un budget adeguato e una reasoned roadmap

Attenzione: sostituire un controllo OCX con una pagina web moderna non è sostituire ActiveX — è spesso riscrivere un pezzo di applicazione.

8. Una tabella di mappatura per troubleshooting

9. Riassunto

I tre termini si distinguono così.

• COM è il fondamento
• ActiveX è il contesto di componenti COM embeddabili
• OCX è il file che comunemente vedi per i controlli ActiveX

Una volta separati, diventa molto più facile vedere

• se è semplicemente un .ocx
• se è un problema COM generale
• se dipende dal browser
• se è un componente che può restare in desktop

La tecnologia legacy non è difficile perché i nomi sono vecchi — è confusa perché fondazione, componenti e file appaiono tutti nella stessa conversazione. Ma una volta visibile la struttura, si rivela un problema sorprendentemente gestibile.

10. Articoli correlati

• Perché il design di Windows COM è ancora bello
• Come gestire ActiveX / OCX oggi - Una tabella decisionale Keep / Wrap / Replace
• Perché ActiveX smette di funzionare in Office 2024 / Microsoft 365 e come diagnosticarlo

11. Riferimenti

• 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

Articoli correlati

Articoli recenti con gli stessi tag per approfondire argomenti vicini.

Argomenti correlati

Queste pagine collocano l’argomento in un contesto più ampio di servizi e decisioni.

Servizi collegati all’argomento

L’articolo è direttamente collegato ai servizi seguenti.

Domande frequenti

Domande che ricorrono nelle consulenze sull’argomento dell’articolo.

Qual è la differenza tra COM, ActiveX e OCX?

In sintesi, COM è la tecnologia di base per componenti binari su Windows. ActiveX è la parola usata quando quei componenti COM sono incorporabili in altre app o nelle pagine web, come controlli UI. OCX è un'estensione di file comune per le ActiveX control basate su COM. In molte conversazioni i tre nomi vengono mescolati, ma separarli aiuta a ragionare: COM è il fondamento, ActiveX è il contesto, OCX è la tipologia di file.

I controlli OCX sono pericolosi e andrebbero eliminati subito?

Non necessariamente. I controlli OCX sono semplicemente file che contengono controlli ActiveX/COM. Il problema di sicurezza sorge quando vengono caricati in contesti non attendibili come Internet Explorer, dove vulnerabilità specifiche possono essere sfruttate. In un'app desktop attendibile o in un ambiente intranet gestito, l'OCX continua a funzionare. La decisione corretta dipende da dove gira: se è esposto a contenuto non attendibile del web, sostituirlo o isolarlo è ragionevole; se vive dietro a una UI desktop, il problema è più manutenzione e supporto che sicurezza immediata.

Perché un controllo OCX che funzionava ha smesso di funzionare su Windows nuovi?

Le cause più comuni sono: disinstallazione durante un aggiornamento di sicurezza; mancanza di .ocx a 64-bit se si è passati a Office 64-bit; perdita della registrazione COM (spesso richiede regsvr32 con privilegi amministratore); dipendenza mancante da Visual C++ Redistributable o .NET Framework; conflitto di bitness; o blocchi da parte di Protected View / macro security di Office. Iniziare da regsvr32 e Process Monitor/Process Explorer per tracciare NAME NOT FOUND / DLL non caricate è il percorso più diretto.

Posso portare un OCX a .NET e sbarazzarmi del file .ocx?

Sì, se hai accesso al sorgente o puoi riprogettare il componente, ma non è una risposta semplicemente "sostituiscilo con WinForms/WPF". Se il controllo OCX è una UI attiva con dipendenze grasse, la riscrittura è un progetto a sé. Se il componente svolge solo un calcolo o un'elaborazione dietro, wrapparlo in un server COM .NET o sostituirlo con una libreria C# può essere più veloce. Spesso il percorso pragmatico è: tenere il componente esistente dove funziona, isolare il confine COM, e sostituire progressivamente le parti che non servono più.

Profilo dell’autore

Pagina di presentazione dell’autore dell’articolo.

Go Komura

Rappresentante di KomuraSoft LLC

Specializzato nello sviluppo di software Windows, nella consulenza tecnica e nell’analisi dei malfunzionamenti, soprattutto nei progetti con sistemi esistenti e guasti difficili da riprodurre.