Что такое COM / ActiveX / OCX — различия и связь

Три слова — COM / ActiveX / OCX — в Windows-проектах с легаси почти всегда приходят пакетом.

• Вендор присылает .ocx
• На экране Access или VB6 висит непонятный компонент
• Только что сказали «это COM», и сразу вслед — «это же ActiveX»
• Потом разом набегают regsvr32, 32-бит / 64-бит, режим IE

На этом этапе разговор обычно перестаёт сходиться. Термины близки, да и исторически они сильно пересекаются. Обратная сторона: если их научиться разделять, исследовать, переносить и объяснять становится заметно проще.

flowchart TB
    accTitle: Почему разговор перестаёт сходиться
    accDescr: Когда близкие термины COM, ActiveX и OCX всплывают на площадке одновременно, разговор перестаёт сходиться; если отделить, что является основой, что компонентом, а что файлом, исследовать, переносить и объяснять становится проще.
    mix["Три слова приходят разом"] --> lost["Разговор не сходится"]
    split["Отделить основу, компонент и файл"] --> clear["Исследовать, переносить и объяснять проще"]

Рис. 1: Цель статьи одна. Отделить, что здесь основа, что компонент, а что файл.

В этой статье разберём что такое COM, что такое ActiveX и что такое OCX в таком порядке, чтобы были видны различия и связь. В особенности проясним, что является основой, что компонентом, а что файлом.

Содержание

1. Сначала вывод (коротко)
2. Что в этой статье понимается под COM / ActiveX / OCX
3. Сначала на одном листе
   • 3.1. Схема связей
   • 3.2. Самый короткий словарь
4. Что такое COM
   • 4.1. Коротко
   • 4.2. Что важно в COM
   • 4.3. Построчные заметки по терминам
5. Что такое ActiveX
   • 5.1. Коротко
   • 5.2. ActiveX — не только для браузера
6. Что такое OCX
   • 6.1. Коротко
   • 6.2. Чем отличается от .dll
7. Различия в таблице
8. Где это применялось
9. Почему это легко перепутать
10. Как к этому относиться в сегодняшней практике
11. Частые заблуждения
12. Что проверять при исследовании
13. Итог
14. Источники

Карта знаний этой статьи

COM — фундамент, на котором компоненты в Windows обмениваются по бинарному контракту; ActiveX — контекст многократно используемого компонента на базе COM и OLE/Automation, который встраивают в хост или контейнер. OCX — лишь часто используемое расширение файла реализации такого элемента управления ActiveX, а не само понятие. ActiveX давно применяют не только в браузере, но и в приложениях Windows — VB6, MFC, COM-обёртка из WinForms и т. д. CLSID и ProgID, библиотека типов и модель apartment STA/MTA поддерживают идентификацию и вызов COM; регистрация с правами администратора через regsvr32 и совпадение разрядности 32-bit/64-bit определяют размещение OCX. Браузерный ActiveX продолжает работать в расчёте на режим IE как мост обратной совместимости.

flowchart LR
    accTitle: Карта знаний COM, ActiveX и OCX
    accDescr: Схема, которая показывает, как на фундаменте COM надстраиваются OLE/Automation и ActiveX и доходят до файла реализации OCX; как CLSID, ProgID, библиотека типов и модель apartment обеспечивают идентификацию и вызов COM; регистрацию с правами администратора через regsvr32 и ограничение совпадения разрядности; и конструкцию, в которой браузерный ActiveX зависит от режима IE
    com["COM (Component Object Model)"]
    activex["ActiveX"]
    ocx["OCX"]
    ole_automation["OLE/Automation"]
    clsid["CLSID (Class ID)"]
    progid["ProgID (Programmatic Identifier)"]
    vb6["Visual Basic 6.0 (VB6)"]
    type_library["библиотека типов (TLB)"]
    dotnet[".NET (начиная с Core)"]
    com_apartment_model["модель апартаментов COM (STA/MTA)"]
    regsvr32["regsvr32"]
    admin_rights["права администратора"]
    bitness_match_requirement["требование совпадения разрядности"]
    ie_mode["режим IE"]
    mfc["MFC (Microsoft Foundation Classes)"]
    windows_forms["Windows Forms"]
    dumpbin["dumpbin"]
    activex -->|"использует"| com
    ocx -->|"реализует"| activex
    ole_automation -->|"использует"| com
    activex -->|"использует"| ole_automation
    com -->|"использует"| clsid
    progid -->|"использует"| clsid
    vb6 -.->|"использует"| type_library
    dotnet -.->|"использует"| type_library
    com -->|"использует"| com_apartment_model
    regsvr32 -->|"автоматизирует"| com
    regsvr32 -.->|"требует"| admin_rights
    ocx -->|"настраивается"| regsvr32
    ocx -->|"требует"| bitness_match_requirement
    activex -.->|"требует"| ie_mode
    vb6 -->|"использует"| activex
    mfc -.->|"использует"| activex
    windows_forms -.->|"использует"| activex
    ocx -->|"проверяется"| dumpbin

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 18, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

1. Сначала вывод (коротко)

Сначала грубо, но полезно сформулируем так.

• COM — это основа. Бинарный контракт, по которому компоненты в Windows общаются друг с другом
• ActiveX — это контекст компонентов на базе COM. Особенно часто он проявляется как элементы управления, которые встраивают в хост
• OCX — файл реализации, который часто встречается у ActiveX control. С ним сталкиваются как с расширением файла
• Иначе говоря, картина яснее, если держать так: COM = механизм, ActiveX = контекст компонентов, OCX = файл
• Память вида ActiveX = та опасная штука из старых браузеров наполовину верна, наполовину недостаточна. ActiveX — не только для браузера
• OCX = ActiveX часто говорят почти как синонимы, но строго говоря смешивают концепт и расширение файла
• Сегодня это не та технология, вокруг которой стоит строить новую разработку, но она всё ещё встречается в существующих Windows-приложениях, Office, Access, SDK оборудования и внутренних веб-системах

Всё начинается с того, чтобы разделять эти три вопроса.

1. Речь о самом COM?
2. Речь об ActiveX control?
3. Или это просто так называют, увидев файл .ocx?

Как только это получается различать, туман заметно рассеивается.

flowchart TB
    accTitle: Три вопроса, с которых начинают
    accDescr: Сначала отделяют, идёт ли речь о COM как о механизме, об ActiveX control как о компоненте или просто так называют, увидев файл ocx.
    q{"О чём сейчас речь?"}
    q --> a["COM = речь о механизме"]
    q --> b["ActiveX = речь о контексте компонентов"]
    q --> c["OCX = речь о файле"]

Рис. 2: Запутались — возвращайтесь к этим трём вариантам. COM — механизм, ActiveX — контекст компонентов, OCX — файл.

2. Что в этой статье понимается под COM / ActiveX / OCX

На практике эти три термина часто живут вперемешку. Поэтому сначала зафиксируем значения для этой статьи.

• COM: сама компонентная модель Windows. Основа интерфейсов, GUID, регистрации и вызова
• ActiveX: встраиваемые элементы управления на базе COM и контекст их использования. На практике чаще всего имеется в виду именно ActiveX control
• OCX: расширение файла, которое часто встречается у реализаций ActiveX control. .ocx

Небольшое уточнение: исторически слово ActiveX какое-то время использовалось шире. Но большинство мест, где ActiveX сегодня создаёт трудности, так или иначе крутятся вокруг элементов управления, встраивания, хостов, браузера и регистрации.

Поэтому и в этой статье мы в основном исходим из того, что ActiveX ≈ история про ActiveX control.

flowchart TB
    accTitle: Ширина слова ActiveX и фокус этой статьи
    accDescr: Исторически слово ActiveX какое-то время использовалось шире, но сегодня трудности крутятся вокруг элементов управления, встраивания, хостов, браузера и регистрации, поэтому статья держит фокус ближе к ActiveX control.
    word["Слово ActiveX"] --> wide["Исторически смысл был шире"]
    word --> now["Сегодня трудности — вокруг control"]
    now --> focus["Эта статья идёт ближе к control"]
    now -.-> items["Встраивание, хост, браузер, регистрация"]

Рис. 3: Историческую ширину слова признаём, но фокус фиксируем на «стороне control», где на практике и возникают трудности.

3. Сначала на одном листе

3.1. Схема связей

Общую картину быстрее всего увидеть на одной схеме. Если схема не отображается, сразу под ней тот же смысл повторен списком.

flowchart LR
    COM["COM<br/>Основа бинарного контракта"] --> OLE["OLE / Automation<br/>Механизмы встраивания и автоматизации"]
    OLE --> AX["ActiveX<br/>Контекст control на базе COM"]
    AX --> CTRL["ActiveX control"]
    CTRL --> OCX["OCX (.ocx)<br/>Частая форма файла реализации"]

    HOST["Хост / контейнер<br/>IE / Access / VB6 / MFC / WinForms"] --> CTRL

Рис. 4: На основе COM складываются OLE / Automation, ActiveX и OCX; хост размещает control.

Важно, что COM и ActiveX — не одно и то же слово.

• COM — это основа
• OLE / Automation — механизмы встраивания и автоматизации
• ActiveX проявляется как контекст элементов управления поверх них
• OCX — файл, который часто встречается у таких реализаций control

Поэтому на вопрос ActiveX — это то же самое, что COM? ответ такой: основа — COM, но ActiveX не является самим COM.

3.2. Самый короткий словарь

Если запоминать по минимуму, этого достаточно.

• COM — механизм
• ActiveX — контекст компонентов
• OCX — файл

4. Что такое COM

4.1. Коротко

COM расшифровывается как Component Object Model и представляет собой бинарный контракт, по которому компоненты в Windows общаются друг с другом.

Бинарный контракт здесь — не удобство исходников и не особенности языка, а интерфейс, обещания которого сохраняются и после компиляции. Компонент, написанный на C++, можно использовать из другого языка или другого приложения именно благодаря этому контракту.

Если приблизить к практике, COM — это не столько «удобный способ раздавать библиотеки», сколько механизм, который скрывает реализацию и соединяет всё только через контракт.

Типичные приметы COM такие (значение каждого слова — по одной строке в 4.3).

• подсчёт ссылок через IUnknown
• поиск интерфейсов через QueryInterface
• идентификация на основе GUID через IID и CLSID
• использование in-process через DLL
• использование out-of-process через EXE

Иначе говоря, COM — это основа культуры компонентизации в Windows.

flowchart TB
    accTitle: Идея бинарного контракта
    accDescr: COM соединяет компоненты не удобствами исходников или языка, а бинарным контрактом, который сохраняется и после компиляции, поэтому компонент на C++ можно использовать из другого языка или другого приложения.
    part["Компонент〔реализацию скрывают〕"] --> contract["Бинарный контракт〔публичное обещание〕"]
    contract --> user["Другой язык, другое приложение"]
    contract -.-> note["Обещание сохраняется и после компиляции"]

Рис. 5: Ядро COM — «скрыть реализацию и соединять только контрактом». Поэтому компоненты работают через границы языков.

4.2. Что важно в COM

Если ограничиться основами, в COM важно следующее.

• В центре — интерфейс
  • Сначала решают, что публиковать, и лишь потом — как это реализовать
• Идентификация через GUID
  • Классы и интерфейсы идентифицируются однозначно
• Разделение хоста и реализации
  • Вызывающей стороне не нужно знать внутреннюю реализацию
• Можно пересекать границу процессов
  • Компонент используют не только в том же процессе, но и как компонент в другом процессе

Именно это не даёт списать COM как просто старую технологию. С довольно ранних пор у него была прочная основа для переиспользования на базе контракта.

flowchart TB
    accTitle: Четыре опоры COM
    accDescr: Проектирование вокруг интерфейса, однозначная идентификация через GUID, разделение хоста и реализации и возможность пересекать границу процессов делают COM контрактным переиспользованием.
    com["Основы COM"] --> p1["В центре — интерфейс"]
    com --> p2["Идентификация через GUID"]
    com --> p3["Разделение хоста и реализации"]
    com --> p4["Можно пересекать границу процессов"]

Рис. 6: Четыре опоры COM. Контрактное переиспользование было заложено довольно рано.

4.3. Построчные заметки по терминам

В разговоре про COM следующие слова часто летят без пояснения. Здесь это только вход в концепты — по одной строке. Если интересен уже сам дизайн, см. Что такое COM — почему дизайн Windows COM до сих пор красив.

Статья ограничивается разбором концептов, в детали каждого пункта не идёт. Когда понадобится реализация, слова из этой таблицы удобно брать как поисковые запросы.

flowchart TB
    accTitle: Базовое поведение на основе IUnknown
    accDescr: IUnknown — основа всех COM-интерфейсов: QueryInterface спрашивает другой интерфейс, AddRef и Release двигают подсчёт ссылок, и когда счётчик доходит до 0, компонент освобождается.
    iu["IUnknown〔основа всего〕"] --> qi["Спросить через QueryInterface"]
    qi --> got["Если есть — возвращается указатель"]
    iu --> rc["Считать через AddRef и Release"]
    rc --> zero["Дошло до 0 — компонент освобождают"]

Рис. 7: Три метода IUnknown в центре таблицы терминов делятся на две работы: «спросить» и «считать».

5. Что такое ActiveX

5.1. Коротко

ActiveX проще всего понимать как переиспользуемые программные компоненты на базе COM, и в особенности как элементы управления, которые встраивают в хост или контейнер.

Когда на практике говорят ActiveX, с высокой вероятностью речь об ActiveX control. Сюда относятся кнопки, сетки (grid), графики, календари, вьюеры, компоненты связки с оборудованием.

ActiveX — это не столько огромная самодостаточная технология, сколько компонент, который работает, будучи встроенным в какой-то хост. При таком восприятии сложнее промахнуться.

flowchart TB
    accTitle: Компонент, который работает, будучи встроенным в хост
    accDescr: Когда на практике говорят ActiveX, с высокой вероятностью речь об ActiveX control — кнопках, сетках, графиках, вьюерах, компонентах связки с оборудованием, которые работают внутри хоста или контейнера.
    host["Хост / контейнер"] --> ctrl["ActiveX control"]
    ctrl --> ex1["Сетка или календарь"]
    ctrl --> ex2["Вьюер или связка с оборудованием"]
    ctrl -.-> note["Это не самодостаточная огромная технология"]

Рис. 8: ActiveX точнее держать как «компонент, который работает, будучи встроенным».

5.2. ActiveX — не только для браузера

Впечатление ActiveX = та штука из Internet Explorer довольно устойчиво. Это не ошибка, но это ещё не вся история.

Где применялись ActiveX control:

• формы Access
• приложения VB6 (Visual Basic 6.0)
• контейнеры MFC (Microsoft Foundation Class Library)
• окружение Office / VBA
• использование COM-обёрток из WinForms
• Internet Explorer и контекст совместимой эксплуатации

Иначе говоря, ActiveX — это не браузерная технология, а компонентная технология, которая долго жила и на стороне Windows-приложений.

Не понимая этого, ActiveX во внутренней веб-системе и ActiveX, встроенный в экран Access, легко принять за разные вещи. На самом деле оба — довольно близкие родственники со стороны COM.

flowchart TB
    accTitle: Где применялись ActiveX control
    accDescr: Формы Access, приложения VB6, контейнеры MFC, окружение Office и VBA, COM-обёртки из WinForms, Internet Explorer — ActiveX не только для браузера, он долго жил и на стороне Windows-приложений.
    ax["ActiveX control"] --> d["Access, VB6, MFC"]
    ax --> o["Окружение Office и VBA"]
    ax --> w["COM-обёртка WinForms"]
    ax --> ie["Семейство Internet Explorer"]
    ie -.-> myth["Знаменит в основном отсюда"]

Рис. 9: Заметным ActiveX сделал IE, но большая часть мест применения — на стороне Windows-приложений.

6. Что такое OCX

6.1. Коротко

OCX — это расширение файла, которым часто оформляют реализацию ActiveX control. Увидев .ocx в Windows-окружении, для начала можно подозревать встраиваемый COM-компонент типа элемента управления.

Обычно он встречается здесь:

• поставки вендорских SDK
• старые проекты на VB6 / Access / MFC
• файлы в инсталляторе, которые нужно регистрировать
• компоненты, для которых нужен regsvr32

Важно помнить: OCX — форма файла, а не сам концепт. Поэтому грубый ответ на что такое OCX такой: файл, с которым чаще всего сталкиваются как с телом ActiveX control.

6.2. Чем отличается от .dll

Здесь тоже легко запутаться.

• .ocx довольно уверенно намекает, что это ActiveX control
• .dll может оказаться и обычной библиотекой, и COM-сервером, и зависимой DLL из окружения ActiveX

Увидев .ocx, можно с достаточной уверенностью предположить, что речь об ActiveX; увидев только .dll, вы пока не поймёте, что это такое.

На практике часто стоит такая расстановка:

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

где главную роль играет OCX, а DLL держат его сбоку.

Поэтому на вопрос OCX — это разновидность DLL? по ощущению это близко, но в исследовании безопаснее смотреть на роли раздельно.

flowchart TB
    accTitle: Сколько можно прочитать из расширения
    accDescr: ocx довольно уверенно намекает, что это ActiveX control, а dll ещё может быть обычной библиотекой, COM-сервером или зависимой DLL. На практике часто главную роль играет OCX, а DLL держат его сбоку.
    q{"Какое расширение?"}
    q -->|".ocx"| ax["Почти наверняка сторона ActiveX"]
    q -->|".dll"| unk["Пока непонятно, что это"]
    unk --> roles["Библиотека, COM-сервер или зависимость"]
    ax -.-> pair["Главный OCX, сбоку его держат DLL"]

Рис. 10: По .ocx уже можно попасть в цель; по .dll, пока не разобрана роль, непонятно, что это.

7. Различия в таблице

Если запоминать по этой таблице, начните с этого.

• COM — фундаментные работы
• ActiveX — культура компонентов поверх этого фундамента
• OCX — файл, который подбирают прямо на площадке

8. Где это применялось

Из-за сильной памяти о браузере ActiveX / OCX часто выглядят как старая веб-технология. На самом деле их применяли значительно шире.

Конкретно — в таких местах.

• Десктопные приложения
  • VB6
  • MFC / C++
  • формы Access
  • окружение Office / VBA
• Браузеры / внутренние веб-системы
  • вьюеры, встроенные в Internet Explorer
  • компоненты подписи
  • компоненты передачи файлов
  • компоненты связки с периферийным оборудованием
• Существующие .NET-приложения
  • существующие ActiveX control, обёрнутые для использования из WinForms
  • случаи, когда существующие COM-наработки продлевают жизнь в роли UI-компонентов

И здесь мы снова возвращаемся к тому, что ActiveX — не технология только для интернета. Он выглядит как веб-технология потому, что был особенно заметен в IE; по сути же и на практике точнее видеть в нём технологию встраиваемых компонентов Windows.

flowchart TB
    accTitle: Расхождение видимости и сути
    accDescr: Из-за того что ActiveX был особенно заметен в IE, он выглядит как старая веб-технология, но на деле применялся широко в десктопных приложениях, внутренних веб-системах и существующих .NET-приложениях; суть — технология встраиваемых компонентов Windows.
    look["Память о том, как это было заметно в IE"] --> web["Выглядит как старая веб-технология"]
    real["Реальные места применения"] --> r1["Десктопные приложения"]
    real --> r2["Браузер и внутренний веб"]
    real --> r3["Существующие .NET-приложения"]
    r1 -.-> truth["Суть — технология встраиваемых компонентов Windows"]

Рис. 11: Расхождение между видимостью «старая веб-технология» и сутью «технология встраиваемых компонентов Windows».

9. Почему это легко перепутать

9.1. Слова разных уровней появляются в одном разговоре

• COM — это речь об основе
• ActiveX — это речь о контексте компонентов
• OCX — это речь о файле

Изначально это разные уровни, но на практике они всплывают одновременно на одной площадке, поэтому разговор легко превращается в кашу.

9.2. Слово ActiveX немного широкое

У COM значение сравнительно устойчивое. ActiveX, напротив, используется чуть шире — и исторически, и на практике.

В зависимости от человека под этим может иметься в виду:

• сам элемент управления
• файл .ocx
• старый компонент, который работает в IE
• встраиваемые компоненты на базе COM в целом

И эти значения расходятся. На этом этапе разговор уже не сходится.

9.3. Стоит увидеть .ocx, как хочется назвать всё подряд ActiveX

Это желание понятно. Для повседневного разговора обычно этого достаточно.

Но в задачах миграции или исследования, если не проверить отдельно,

• является ли это UI-компонентом
• в каком хосте это работает
• нужна ли регистрация
• как обстоят дела с 32-бит / 64-бит
• есть ли зависимость от браузера

позже это обязательно вылезет.

flowchart TB
    accTitle: Три причины путаницы
    accDescr: Путаницу дают три вещи: в одном разговоре смешиваются разные уровни, слово ActiveX чуть широкое, и стоит увидеть ocx, как хочется назвать всё подряд ActiveX.
    r1["Речь разных уровней в одном разговоре"] --> mixup["Разговор превращается в кашу"]
    r2["Слово ActiveX широкое"] --> mixup
    r3["Увидев ocx, называют всё подряд так"] --> mixup
    mixup -.-> risk["В миграции и исследовании это вылезает"]

Рис. 12: Суть путаницы в том, что основа, компонент и файл — разные уровни — появляются на одной площадке одновременно.

10. Как к этому относиться в сегодняшней практике

Прежде всего: находка COM / ActiveX / OCX ещё не значит, что всё нужно сразу отвергнуть. Но и относиться ко всему с одной температурой тоже опасно.

Зависимость от ActiveX на стороне браузера

Это безопаснее рассматривать в первую очередь и достаточно жёстко.

• Это не часть основного направления современной разработки браузеров
• В контексте совместимой эксплуатации всплывает режим IE, но его лучше воспринимать как мост для обратной совместимости
• Опираться на него как на предпосылку для чего-то нового сложно рекомендовать

Для решения нужна ещё и временная шкала. Десктопное приложение IE11 уже выведено из эксплуатации; оставшаяся опора — режим IE в Microsoft Edge. По этому режиму IE Microsoft держит курс поддерживать как минимум до 2029 года и предупреждать об отмене за год. То есть 2029 — это не «до тех пор можно ничего не делать», а срок, к которому отделение нужно закончить, и от него считают назад. Сами шаги отделения разобраны отдельно в Как избавиться от зависимости внутренних веб-систем от режима IE.

Для веб-стороны ActiveX реалистичнее думать в терминах «с какого места начать отделение», а не «как продлить жизнь».

flowchart TB
    accTitle: Временная шкала ActiveX на стороне браузера
    accDescr: Десктопное приложение IE11 уже выведено, оставшаяся опора — режим IE в Edge; Microsoft держит курс поддерживать как минимум до 2029 года и предупреждать об отмене за год. 2029 — не срок, до которого можно ничего не делать, а срок, к которому отделение нужно закончить.
    ie11["Десктопный IE11 уже выведен"] --> iem["Оставшаяся опора — режим IE в Edge"]
    iem --> y2029["Поддержка как минимум до 2029"]
    y2029 --> plan["Считать назад как срок окончания отделения"]
    y2029 -.-> notice["Курс: об отмене предупреждать за год"]

Рис. 13: 2029 — не отсрочка, а дедлайн. На стороне браузера думают в терминах «с чего начать отделение».

Зависимость от ActiveX / OCX на стороне десктопа

Здесь можно судить чуть прагматичнее.

• Стабильно работает внутри существующего хоста
• Круг поставки ограничен
• Есть перспектива поддержки — вендорской или собственной
• Понятны предпосылки о регистрации, зависимых DLL, разрядности

Если эти условия выполняются, решение оставить — вполне нормальное.

С другой стороны, если:

• хочется загрузить 32-битный OCX напрямую в 64-битную сторону
• хочется перевести на .NET только окружение
• поставка и регистрация каждый раз ломаются
• остаётся зависимость от браузера

то безопаснее рассматривать оставить / обернуть / заменить как отдельные варианты.

Сегодняшняя практика спрашивает не о том, плохо ли, что это ActiveX, а о том, где провести границу. Если смотреть на это не как на старую технологию, а как на стык существующей системы, с этим становится заметно легче работать.

flowchart TB
    accTitle: Как расходятся решения на стороне десктопа
    accDescr: Если стабильная работа, ограниченная поставка, перспектива поддержки и понимание предпосылок есть, решение оставить — нормальное; если есть столкновение разрядности, частичный перевод на .NET, сбои поставки или зависимость от браузера, отдельно рассматривают оставить, обернуть и заменить.
    q{"Условия выполнены?"}
    q -->|"стабильная работа и понимание предпосылок"| keep["Решение оставить — нормальное"]
    q -->|"есть узкие места"| split["Отдельно: оставить, обернуть, заменить"]
    split -.-> view["Как стык: где провести границу"]

Рис. 14: На стороне десктопа температуру разделяют. Вопрос не в добре и зле, а в положении границы.

11. Частые заблуждения

Заблуждение 1: COM = ActiveX

Нет. COM — это основа, ActiveX — контекст элементов управления поверх неё.

Заблуждение 2: ActiveX = Internet Explorer

Нет. IE действительно сделал ActiveX известным, но ActiveX — не только для браузера.

Заблуждение 3: ActiveX = OCX

На практике слова используют в очень похожем смысле, но строго говоря это разные вещи. ActiveX — речь о контексте и компонентах, OCX — физическая форма, с которой сталкиваются как с расширением файла.

Заблуждение 4: OCX — это просто DLL, разве нет?

Грубо говоря, это близко, но в исследовании так грубо лучше не быть. Одного .dll недостаточно, чтобы понять роль, тогда как .ocx довольно сильно пахнет элементом управления.

Заблуждение 5: COM — это уже мёртвая технология

По крайней мере в мире Windows так говорить слишком грубо. Она просто отошла со сцены на второй план, но в контекстах проектирования и взаимодействия встречается и сегодня.

flowchart TB
    accTitle: Как поправить частые заблуждения
    accDescr: COM — не сам ActiveX, а основа; ActiveX не только для IE; ActiveX и OCX различаются как концепт и файл; COM — не мёртвая технология.
    m1["COM = ActiveX?"] --> a1["COM — основа, это другое"]
    m2["ActiveX = только IE?"] --> a2["На десктопе тоже в ходу"]
    m3["ActiveX = OCX?"] --> a3["Разница концепта и файла"]
    m4["COM уже мёртв?"] --> a4["Во взаимодействии встречается и сейчас"]

Рис. 15: Все пять заблуждений рождаются из смешения разных уровней.

12. Что проверять при исследовании

Найдя COM / ActiveX / OCX, меньше шансов заблудиться, если идти по этим пунктам по порядку.

1. Что это за компонент
   • UI-элемент управления?
   • вьюер?
   • связка с оборудованием?
   • связка с Office / Access?
2. Где это работает
   • Access / VBA?
   • VB6 / MFC?
   • WinForms?
   • IE / режим IE?
3. Какие файлы и идентификаторы
   • .ocx / .dll / .exe
   • ProgID
   • CLSID
   • Type Library
4. Как обстоят дела с регистрацией и поставкой
   • нужен ли regsvr32?
   • есть ли зависимые DLL?
   • нужны ли права администратора?
5. Совпадает ли разрядность
   • 32-бит?
   • 64-бит?
   • нужно ли работать в одном и том же процессе?
6. Как поступать с этим дальше
   • оставить как есть?
   • провести границу и обернуть?
   • заменить?

12.1. Чем это смотреть

Шесть пунктов выше — «на что смотреть». Рядом полезно держать и «куда открыть». Без этого даже при чек-листе первый шаг стопорится.

Если, не пройдя по этому, броситься с фразой раз есть ActiveX, реализуем всё заново с нуля, вы аккуратно наступите на все старые грабли. Сначала заполните соответствие шести пунктов и инструментов, и уже потом решайте «оставить / обернуть / заменить» из главы 10 — так безопаснее.

flowchart TB
    accTitle: Порядок исследования
    accDescr: По порядку смотрят, что это за компонент, где он работает, какие файлы и идентификаторы, как устроены регистрация и поставка, совпадает ли разрядность — и уже потом решают оставить, обернуть или заменить.
    s1["Смотрят, что это за компонент"] --> s2["Смотрят, где работает"]
    s2 --> s3["Разбирают файлы и идентификаторы"]
    s3 --> s4["Проверяют регистрацию и поставку"]
    s4 --> s5["Проверяют разрядность"]
    s5 --> s6["Решают: оставить, обернуть или заменить"]

Рис. 16: Не бросаться сразу в новую реализацию. Безопаснее заполнить этот порядок и уже потом выбирать направление.

13. Итог

Если формулировать различия COM / ActiveX / OCX максимально грубо, но полезно для практики, получится так.

• COM — основа
• ActiveX — контекст встраиваемых компонентов на базе COM
• OCX — файл, который часто встречается у ActiveX control

Научившись разделять эти три понятия, вы заметно легче начинаете видеть:

• это просто .ocx или нет
• это проблема COM в целом
• это ActiveX, завязанный на браузер
• это компонент, который можно оставить на десктопе

Легаси-технология сложна не потому, что название старое, а потому, что основа, компоненты и файлы появляются в одном и том же разговоре. Но стоит увидеть структуру — и неожиданно оказывается, что с этим вполне можно работать.

14. Источники

• Что такое COM — почему дизайн Windows COM до сих пор красив
• Как сегодня поступать с ActiveX / OCX: оставить, обернуть или заменить
• Компонентная объектная модель (COM) - Microsoft Learn
• Элементы управления ActiveX - Win32 apps - Microsoft Learn
• ActiveX Controls - MFC - Microsoft Learn
• ActiveX Control - Access VBA - Microsoft Learn
• Что такое режим Internet Explorer (IE) - Microsoft Learn
• Вопросы и ответы о жизненном цикле IE и Edge - Microsoft Learn (курс поддерживать режим IE как минимум до 2029 года)
• regsvr32 - команды Windows - Microsoft Learn
• Ключ CLSID - Win32 apps - Microsoft Learn
• Перенаправление реестра - Win32 apps - Microsoft Learn
• Использование DevTools в режиме Internet Explorer (режим IE) - Microsoft Learn

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Что такое файл OCX?

OCX — расширение файла, которым часто оформляют реализацию ActiveX control. Увидев .ocx в Windows-окружении, для начала можно подозревать встраиваемый COM-компонент типа элемента управления. Обычно это поставка вендорского SDK, часть старого проекта на VB6 / Access / MFC, файл в инсталляторе, который нужно регистрировать, или компонент, для которого нужен regsvr32. Путаницы меньше, если помнить: OCX — форма файла, а не сам концепт.

Чем COM отличается от ActiveX?

COM — бинарный контракт, по которому компоненты в Windows общаются друг с другом, то есть основа. ActiveX — переиспользуемые программные компоненты на базе COM; чаще всего слово указывает на контекст элементов управления, которые встраивают в хост или контейнер. Картина яснее, если держать так: «COM = механизм, ActiveX = контекст компонентов, OCX = файл». Основа ActiveX — COM, но ActiveX — это не сам COM.

ActiveX — это технология только для Internet Explorer?

Нет. IE действительно сделал ActiveX известным, но ActiveX control давно жили и на стороне Windows-приложений: формы Access, приложения VB6, контейнеры MFC, окружение Office / VBA, COM-обёртки из WinForms. На практике точнее видеть в этом не браузерную технологию, а технологию встраиваемых компонентов Windows. Зависимость от ActiveX в браузере сегодня реалистичнее рассматривать не как «как продлить жизнь», а как «с чего начать отделение».

Чем OCX отличается от DLL?

Расширение .ocx довольно уверенно намекает, что это ActiveX control, а .dll может оказаться и обычной библиотекой, и COM-сервером, и зависимой DLL из окружения ActiveX. На практике часто главную роль играет vendorcontrol.ocx, а DLL вроде vendorhelper.dll держат его сбоку. Если спросить, является ли OCX разновидностью DLL, по ощущению это близко, но в задачах исследования или миграции безопаснее смотреть на роли раздельно.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.