Каков наилучший способ изолировать новый код C++ от более старого (двоичного) компонента с помощью другой CRT?

Я работаю над большой базой кода для настольного приложения Windows, написанного на C++.

Много лет назад моя компания заплатила лицензионный сбор гораздо более крупной компании за использование компонента, встроенного в наше программное обеспечение и предоставляющего критически важные услуги. Компонент представляет собой двоичный BLOB-объект с некоторыми файлами заголовков и был скомпилирован с использованием среды выполнения VS2008.

В результате сейчас все приложение зависит от среды выполнения VS2008. Мы не можем перейти на современный C++ или более новые версии используемых нами библиотек (например, мы застряли на Qt4, а не на Qt5). По разным причинам маловероятно, что указанная компания когда-либо предоставит обновленные BLOB-объекты, и, хотя мы планируем написать собственную замену, это займет много времени.

Тем временем я хотел бы каким-то образом обернуть этот компонент и изолировать его, чтобы мы могли обновить остальную часть нашего кода до более поздней среды выполнения и общаться с ним с помощью JSON или аналогичного. Потенциально в какой-то момент в будущем мы можем заменить компонент чем-то собственным (или чем-то с открытым исходным кодом), вообще не написанным на C++.

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

Я заинтересован в любых предложениях относительно наилучшего способа продолжить. Пока мои идеи таковы:

  • Очень тщательно спроектируйте DLL (которая может работать или не работать, я не могу сказать по Как мне создать независимую от версии среды выполнения DLL на C++?, но похоже, что это будет неоптимально)
  • Используйте COM (см. оговорки выше)
  • Запускать как отдельный процесс и передавать данные через cin и cout (ограничено текстовыми данными и может быть медленным?)
  • Запустите как отдельный процесс и запустите простые отношения клиент/сервер (кажется тяжеловесным)

c++ com msvcrt
person UnmightySten    schedule 09.07.2020    source источник
comment
Какая проблема будет связана с Windows, если вы в настоящее время привязаны к VS2008? Привязка к VS2008 уже подразумевает привязку к Windows.   -  person MSalters    schedule 09.07.2020
comment
У вас уже есть варианты, какой из них лучше для вас, трудно сказать без минимально воспроизводимого примера   -  person Alan Birtles    schedule 09.07.2020
comment
Если указанная библиотека создается динамически с помощью CRT, единственным вариантом, который у вас есть, является взаимодействие между процессами. Характер такой связи будет определяться фактическими функциями, предоставляемыми библиотекой.   -  person SergeyA    schedule 09.07.2020
comment
Это не серьезная проблема, но, кроме проблемного компонента, все остальное — это C++ и Qt, и поэтому они практически не зависят от ОС. Мой естественный инстинкт — максимально избегать зависимости от платформы.   -  person UnmightySten    schedule 09.07.2020
comment
Хост dll в другом процессе кажется чистым. Но вы потеряете производительность. Части COM, которые вам нужны, очень далеки от отказа. COM есть везде в Windows, в том числе и в новом WinRT. Это даже позволяет вам делать x64-x86 ipc. Я бы выбрал СОМ.   -  person Simon Mourier    schedule 09.07.2020

Ответы (1)


arrow_upward
-1
arrow_downward

COM активно не развивается в основном потому, что он закончен. Тем не менее, он активно поддерживается. Например, когда Windows стала 64-битной, COM также был перенесен на 64-битную версию. Он получает обновления безопасности, когда это необходимо.

DCOM — это распределенный вариант COM. Я бы не беспокоился; вы просто проектируете все для работы на одном ПК с использованием одной учетной записи пользователя. Это уже то, как ваше приложение работает в любом случае.

VS2008 вполне может использовать строки BSTR поверх (D)COM, а в VS2019 для этого есть удобная оболочка _bstr_t. (Я не помню, было ли в VS2008 уже _bstr_t).

Обычно вам не нужно использовать все функции COM. COM был разработан как платформа взаимодействия между множеством различных приложений, но у вас есть две части кодовой базы, написанные одними и теми же разработчиками, которые должны работать только друг с другом. Нет необходимости динамически обнаруживать интерфейсы COM и так далее. Вы можете просто поделиться файлом .h с определениями интерфейса.

person MSalters    schedule 09.07.2020
comment
› COM активно не развивается в основном потому, что он закончен. Он активно поддерживается, хотя я не смотрел на это таким образом. Это очень ясно, и COM кажется технологией, наиболее подходящей для того, что я хочу сделать. Кажется, это правильный путь: тем более, что вы указываете, что нам не нужно использовать некоторые из более тяжелых вещей. Спасибо за ваш ответ. Теперь нужно найти достойный ресурс «Начало работы с COM», который актуален :) - person UnmightySten; 10.07.2020