Плагины с очень сильным использованием функционала основного приложения

Добрый день!

Имеется программа на GNU C++ для проведения весьма сложных инженерных расчетов. В ней пользователь составляет расчетные схемы промышленных объектов из очень большого набора устройств и производит их моделирование. В каком-то очень упрощенном смысле работа похожа на расчет электрических схем (хотя к электричеству отношения почти не имеет). Добавляем на схему резисторы, транзисторы, микросхемы, настраиваем их параметры и рассчитываем все токи и напряжения.

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

В начале была попытка организовать работу плагинов через два типа интерфейсов IPlugin для плагинов и IMainApp для основного приложения. Однако быстро выяснилось, что такой подход практически сводит на нет функциональные возможности плагинов. Дело в том, что для полноценной работы плагину нужна львиная доля функционала основного приложения. Именно в этом смысл продукта, так как создание расчетной модели каждого элемента схемы может быть сравнимо с написанием диплома или даже диссертации. Поэтому интерфейс IMainApp, по сути, должен был содержать значительную часть классов основного приложения.

Поэтому было реализовано другое решение. Процентов 80 от основной программы было выделено в две большие динамические библиотеки. Одна предоставляет ворох возможностей для технических расчетов, другая служит для работы со структурными техническими схемами. Обе библиотеки представлены в виде динамических библиотек lib.dll, соответствующих им статических библиотек lib.a и наборов заголовочных файлов *.h. Эти файлы совместно с документацией объединены в SDK для плагинов. Самый важный момент: при сборке каждый плагин линкуется со обеими статическими библиотеками. Это дает возможность при загрузке плагина в приложение использовать весь функционал последнего. По сути, плагин становится просто частью основной программы. Результаты получились выше всяких похвал, функциональные возможности плагинов выходят просто замечательные.

Минусом является то, что для каждой новой версии продукта необходимо выпускать новую версию SDK с актуальными библиотеками, указывать версию MinGW/GCC и пересобирать все плагины. Но это совершенно не пугает, это для нас нормально.

Тем не менее терзают вопросы:
1. Не является ли это решение (линковка плагинов со статическими библиотеками основного приложения) в корне неверным, так как существует другой гораздо более удачный подход?
2. Не является ли вынос основного движка продукта в динамические библиотеки (и соответствующие им статические) серьезной угрозой безопасности продукта? Планируется реализовать защиту этих библиотек в том числе с помощью USB-ключей. Но тем не менее…
3. Какие возможные действия можно предпринять для снижения опасности реверс-нижиниринга для этих библиотек?

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

0

Возможно, я ошибаюсь в терминологии (не ругайте, я инженер, а не профессиональный программист).

Библиотеки wxWidgets и common - динамические, в код плагина не вливаются. Но при их компиляции под виндой создаются мелкие библиотеки импорта .a, которые линкуются при сборке основного проекта и плагина.

Миниатюры

 

Изображения

 

0

Сообщение от steevis Библиотеки wxWidgets и common - динамические, в код плагина не вливаются. Но при их компиляции под виндой создаются мелкие библиотеки импорта .a, которые линкуются при сборке основного проекта и плагина.

Ну значит это мелкая техническая подробность конкретной платформы, зачем пугать общественность "статической" линовкой?

Сообщение от steevis Основные положения:

А может Вы просто переоцениваете проблемы? Почему бы не действовать прямолинейно, "по пути наименьшего сопротивления"? Плагину нужен wxWidgets? Подключим ее к плагину. Нужна (большая) либа для расчетов? Тоже подключим. Какие проблемы? Почему это не должно работать?

Только нужно не просто "загрузить либу", а именно ту ее "instance" что в хосте. Чтобы все переменные/установки сделанные хостом были видимы в плагине (пример qApp выше) и наоборот. Др словами инстансы либ в плагине и хосте должны юзать одни те же данные. Как это сделать в вындоуз - читал очень давно, помню только что так делать можно. Ничего, разберетесь

0

И вообще как не прогер, позволю себе глобальный совет, ибо жираф большой, ему видней
в линукс все в мелких пакетах, ну зачем писать большой функционал в одной большой
проге, каждая функция в отдельном пакете (это же конгениально), обновил функцию
обновил версию пакета, и не надо потом мучаться, что можно показать заказчику

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

0