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

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

0 голосов
/ 09 июля 2020

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

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

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

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

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

Меня интересуют любые предложения относительно того, как лучше всего действовать. На данный момент мои идеи:

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

1 Ответ

0 голосов
/ 09 июля 2020

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

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

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

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

...