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

Добрый день!

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

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

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

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

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

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

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

0

Спасибо за важные замечания!

Нужно отметить следующую особенность. Пользователи продукта - исключительно научно-технические и промышленные предприятия. Со всеми ними имеется самое тесное взаимодействие: совместная работа, консультации, техподдержка. Плагины, скорее всего, будут писаться под пристальным вниманием вендора.

Со временем можно думать и о отдельном API на C и о своих скриптах, но пока задача запустить и обкатать самый первый вариант работы.

0

Сообщение от COKPOWEHEU Вариант с OpenGL все же более показателен. Программа вынуждена подгружать список функций в рантайме, чтобы взаимодействовать именно с выбранным драйвером видеокарты.

Смотря в каком смысле "показателен". По-моему это классический пример как сдохло/захлебнулось C API. Все слишком разрослось, куски стали наползать друг на друга. Пришлось отказаться от такого подхода, заметим что "отрубить хвосты" оказалось очень непросто.

Сообщение от jcxz Все нормальные API пишутся так, чтобы их можно было вызывать хоть из си, хоть из си++.

Лучше сказать

Простые и хорошие API пишутся так, чтобы их можно было вызывать хоть из си, хоть из си++.

С этим никто не спорит, но никто не обещал что будет "просто"

Сообщение от vlisp плагины это вообще другое. ну, вот совсем

Ход мысли начинающего который честно выучил и знает "правельный ответ"

Сообщение от COKPOWEHEU Но у ТС явно не тот случай: хранить все чужие плагины и поддерживать репозиторий он скорее всего не сможет. Тут лучше бы все-таки скриптовый язык или динамическая подгрузка.

Да, с репозиторием явно узкое место. Скриптовый язык - дело хорошее, но это другой разговор. А подгрузка - разве сейчас она не динамическая? Разве сейчас плагины не используют те же либы что и хост?

Может в данном случае лучше вместо "плагины" уместнее использовать термин "SDK"

Добавлено через 15 минут
Или даже "Framework" (по-нашему )

0

Сообщение от Igor3D Или даже "Framework"

Мне нравится!

0

Сообщение от Igor3D Ход мысли начинающего который честно выучил и знает "правельный ответ"

правильный. таких прожектеров тут встречал. кстати любое уравнение решается достаточно просто

0

Сообщение от Igor3D Все слишком разрослось, куски стали наползать друг на друга. Пришлось отказаться от такого подхода

Какие куски OpenGL стали наползать друг на друга и где от такого подхода отказались?

Сообщение от Igor3D А подгрузка - разве сейчас она не динамическая?

Подгрузка-то динамическая, но только ядро -> плагин. Сам плагин функции ядра грузит средствами ОС, то есть ядерная библиотека у него прописана в зависимостях. Нет возможности проверить успешно ли оно загрузилось, нет возможности выбрать одну из нескольких альтернативных функций. Даже при изменении списка функций могут быть проблемы.

Сообщение от Igor3D Может в данном случае лучше вместо "плагины" уместнее использовать термин "SDK" Или даже "Framework"

В смысле пусть юзер у себя компилирует всю программу целиком - и ядро, и свой плагин, и все сторонние?

0

Сообщение от COKPOWEHEU В смысле пусть юзер у себя компилирует всю программу целиком - и ядро, и свой плагин, и все сторонние?

Только ранее ТС сообщал следующее:

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

Так что - мимо....

Да и вообще, судя по этому сообщению от ТС:

Сообщение от steevis Разобраться в API и создать реализацию (которая требует десятилетия труда) - это две большие разницы.

Разрабатывался проект очень давно, долго и, в общем, потратили на него много ресурсов. А значит и кода там дофига и прочих "скрытых ништяков" (ну там зависимости всякие, как в самом коде, так и от сторонних либ и прочее, которое обязательно вылезет при глобальной перестройке ). Здравый смысл говорит - что ежели работает - НЕ ЛЕЗЬ!!!

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

0

Сообщение от COKPOWEHEU В смысле пусть юзер у себя компилирует всю программу целиком - и ядро, и свой плагин, и все сторонние?

К чему бы я стремился. Есть относительно небольшой ф-ционал "обычного" плагина. Предполагаю что вряд ли плагин должен рисовать созданную микросхему в окнах или писать/читать ее на диск и.т.п., этим занимается хост. А вот все остальное, дебри расчетов - просто подключить (большую) динамическую либу, ту самую что уже загрузил хост. Это обеспечивает доступ ко всем глобальным переменным что установил хост. Ничего "кривого" здесь нет, разве плагин не может юзать другие либы? И что с того что они также юзаются хостом? В OSX можно указать загрузку из пути хоста. С версией конечно гемор обеспечен, ну то уже следующий шаг

0

Сообщение от Recrut_rf Так что - мимо....

"мимо" - что? Я всего лишь пытался уточнить ваше предложение.

Сообщение от Igor3D В смысле пусть юзер у себя компилирует всю программу целиком - и ядро, и свой плагин, и все сторонние? К чему бы я стремился.

К лишней работе?! Ну то есть функции рисования и так есть в ядре, зачем их каждый раз перекомпилировать или зачем каждый раз перекомпилировать, даже если ничего существенного не изменилось.

Сообщение от Igor3D А разве Вам не известно что уже лет 10 (или 15 ?) новые версии OpenGL не выходят, он объявлен deprecated и рекомендуется переходить на Vulcan/Metal ?

Нет, неизвестно. Не слежу за этим. Но вроде как даже OGL1 еще более-менее живое, не говоря уж о шейдерных OGL3.
Metal вообще не в ту степь, это какое-то извращение Эппла, сопоставимое с DirectX.

Сообщение от Igor3D А ведь начиналось все хорошо. Материал, источники света, текстуры - все как в нормальном 3D приложении.

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

Сообщение от Igor3D Понимаю что критиковать, особенно зная результат, ума много не надо. Лет 30 назад, когда все начиналось, C API и было лучшим решением, или даже единственным.

Так а альтернатива-то какая? Ну не поверю я, что тот же Vulkan невозможно использовать из программ на Си.

0

Сообщение от COKPOWEHEU "мимо" - что? Я всего лишь пытался уточнить ваше предложение.

Понял, я подумал, что вы предложили чтоб узер у себя всё сам из исходников собирал. Ступил я в общем,

В отвлечении от основной темы:

Сообщение от Igor3D А разве Вам не известно что уже лет 10 (или 15 ?) новые версии OpenGL не выходят, он объявлен deprecated и рекомендуется переходить на Vulcan/Metal ?

Да ну завтра выйдет "Хуанг" и скажет, го...но ваш Vulcan - мы придумали новую вещь. А чтоб её использовали повсеместно - проведёт окучивание масс, в том числе с занесением кому надо всяких ништяков вечно зелёных.

Сообщение от COKPOWEHEU Ну что поделать, видимо, современным игроделам ее недостаточно...

Может я не прав, но мне кажется, что проблема в том, что я выше написал.

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

0

Сообщение от COKPOWEHEU К лишней работе?! Ну то есть функции рисования и так есть в ядре, зачем их каждый раз перекомпилировать или зачем каждый раз перекомпилировать, даже если ничего существенного не изменилось.

Создатель плагина компилирует только свой плагин. Плюс ему известно какие либы цеплять, они идут вместе с хостом (без исходников разумеется)

Сообщение от COKPOWEHEU Нет, неизвестно.

Ну значит я Вам сообщил, теперь известно Больше расскажут люди увлекающиеся играми

Сообщение от Recrut_rf Да ну завтра выйдет "Хуанг" и скажет, го...но ваш Vulcan - мы придумали новую вещь. А чтоб её использовали повсеместно - проведёт окучивание масс, в том числе с занесением кому надо всяких ништяков вечно зелёных.

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

0

Сообщение от Recrut_rf Может я не прав, но мне кажется, что проблема в том, что я выше написал.

Можете повторить то, что "вы выше написали"? А то пока вообще непонятно в чем же проблема OGL 3+.

Сообщение от Igor3D Или даже "Framework"

Сообщение от Igor3D Создатель плагина компилирует только свой плагин. Плюс ему известно какие либы цеплять, они идут вместе с хостом (без исходников разумеется)

То ли вы имеете какое-то странное представление о том, что такое framework, то ли я. Мне-то казалось, что это "каркас", который юзер заполняет своим содержимым и компилирует на своей локальной машине. В контексте задачи ТСа это предоставление юзеру минимально необходимого набора исходников, прекомпилированных библиотек и инструкции, по которой он может собрать все, что нужно. И ядро, и свой плагин, и все сторонние плагины.
Не отрицаю, что неверным может оказаться именно моя трактовка - тогда озвучьте свою.

Сообщение от Igor3D Ну значит я Вам сообщил, теперь известно

Теперь мне известно только ваше мнение об этом, но не объективное положение дел. Никаких подтверждений своей точки зрения вы не озвучили.

0

0

Без API плагины не работают. Тему можно закрывать.

0

API для плагинов, безусловно, есть и будет передаваться их разработчикам. А тему закрывает автор, когда сочтет это необходимым.

0

Сообщение от COKPOWEHEU А то пока вообще непонятно в чем же проблема OGL 3+

Честно сообщу - с графикой никогда не работал, а значит и с OpenGL и с тем, что пришло на замену ему, ну и с Direct3D тоже делов не имел. Так что это просто мнение и возможно ошибочное.

В общем - да нет никаких проблем с OGL 3+, кроме одной - он устаревший, потому как вроде бы ему на смену пришёл Vulkan.
Я рассуждал так:
всякие высокопоставленные дядьки из крупных международных корпораций чаще всего решают что будет актуально, а что нет в плане софта. Им ведь нужно продавать свои железки, а лучший способ это сделать - придумать новый апи, который поддерживается только ихним самым современным железом.

Просто - что мешало вместо выдумывания того же Вулкана, просто взять и добавить всё тоже самое, только в опенгл?
Задал этот вопрос нейронке и получил ответ:
"Потому что архитектура OpenGL была рассчитана на видеокарты 90-х, а Vulkan — на современные GPU. Чтобы сделать OpenGL таким же эффективным, пришлось бы сломать почти всю обратную совместимость."

Уж не знаю - права она или нет. Моих знаний тут явно не достаточно.

Добавлено через 3 минуты

Сообщение от COKPOWEHEU что такое framework

Ну тут то всё предельно ясно и понятно. Фреймвор задаёт строгие правила использования:
- всякие обязательные классы
- строгий порядок инициализации
- прочие вещи

А если просто прилинковал и пользуешься, добавив заголовочный файл - то это обычная либа.

Добавлено через 7 минут

Сообщение от Igor3D Мой интерес чисто утилитарный, теория/определения меня никогда не интересовали. На OSX это выглядит так: нашел нужный framework и дропнул/добавил его фолдер в проект Xcode. Результат тот же что добавил либу, только гораздо комфортнее - хедеры сам найдет, на запуске загрузит либу с учетом версии. Исходников не видел (может потому что не интересовался), никакого "build" тоже, напротив, стандартные фреймворки лежат в системных неизменяемых фолдерах. Это чертовски удобно, а к хорошему быстро привыкаешь

Это скорее напоминает описание пакетного менеджера, того же VCPKG на винде. Запустил команду - он чёт там установил и вуаля - можно пользоваться в Вижуал Студии. В общем, на мой взгляд, это не про фреймворки

0

Спасибо за полезные советы.

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

Основные положения:

1. На библиотеке wxWidgets основана работа всего проекта (как графического интерфейса, так и другой внутренней начинки), так что волей-неволей ее придется оставить. Она собирается в виде *.dll с соответствующими библиотеками импорта *.a. С последними линкуются статически все другие компоненты проекта, в том числе плагины. Переход с одной версии этой библиотеки на другую будет происходить нечасто, возможно раз в год. Библиотека входит в каждое обновление SDK в сконфигурированном и скомпилированном виде для всех операционных систем. Так что разработчику плагинов ничего делать не надо.

2. Библиотека общего функционала данного проекта. Представляет собой некоторое дополнение к библиотеке wxWidgets. Здесь содержатся настроенные под приложение элементы графического интерфейса и большой модуль для объединения всех компонентов документа (в нашем примере это электрическая схема, радиоэлементы, их ножки, настройки методов расчета и т.д.) в единое дерево. Обеспечивает возможность записи и чтения документа из файла, редактирования и проверки данных. Она тоже собирается и поставляется готовой в SDK в виде *.dll с соответствующими библиотеками импорта *.a. С ней линкуются статически другие компоненты проекта, в том числе плагины. Классы этой библиотеки экспортируются через dllexport. Структура библиотеки не секретна, достаточно хорошо видна разработчику плагинов и имеет очень подробную документацию в виде chm. Выпуск версий этой библиотеки примерно раз в полгода-год.

3. Основной расчетный движок выполняется в виде статической библиотеки, использует и линкуется с библиотеками wxWidgets и Common. Для него поверх всего функционала пишется новый слой API, состоящий из абстрактных классов (абстрактная электрическая схема, абстрактный ее элемент, абстрактный коннектор и т.д.). Весь функционал в итоге доступен в плагине через корневой класс Host, который возвращает указатели на крупные абстрактные модули движка. Также этот движок имеет небольшое API, с помощью которого основное приложение инициализирует работу. Линкуется к исполняемому файлу статически, имеет документацию только по абстрактному API. Выделен в отдельную библиотеку для того, чтобы на его основе можно было создавать и другие продукты.

4. В итоге работа плагина в основном сводится к конструированию своих собственных узлов, встраиванию их в общий документ с помощью библиотеки Common и, самое главное, реализацию расчетов через API расчетного движка.

Миниатюры

 

0

Сообщение от Recrut_rf Честно сообщу - с графикой никогда не работал, а значит и с OpenGL и с тем, что пришло на замену ему

Насколько я понимаю, Vulkan - не замена OpenGL, а альтернатива. Более сложная, но и более гибкая. В этом смысле мне OGL1 нравится, он еще проще, но без шейдеров вряд ли может составить конкуренцию. А так, OpenGL живой, что ему сделается.

Сообщение от Recrut_rf всякие высокопоставленные дядьки из крупных международных корпораций чаще всего решают что будет актуально, а что нет в плане софта. <...> что мешало взять и добавить всё тоже самое, только в опенгл?

Ничто не мешало. И именно так они и делают. Всякие GL_EXT именно для этого и нужны.

Сообщение от Recrut_rf "Потому что архитектура OpenGL была рассчитана на видеокарты 90-х, а Vulkan — на современные GPU. Чтобы сделать OpenGL таким же эффективным, пришлось бы сломать почти всю обратную совместимость."

Нечто подобное и я слышал. Разработчики OpenGL хотели сделать чуть ли не javascript, переложить основную работу с видеокартой на драйвер. Вплоть до распределения памяти и ядер.
Но со временем это начало мешать, поэтому сейчас и экспериментируют с другой архитектурой. На настоящий момент - экспериментируют. Выпиливать OpenGL никто не собирается.
С Вулканом я дела не имел (именно потому что для моих скромных задач он излишне сложный), но сильно подозреваю, что там точно такое же C-API. Как и во всех нормальных библиотеках.

1

steevis, не пойму - а зачем использовать .dll и .a одновременно? Или одно для винды, а другое для линуксов?

0

При линковке с помощью GCC под линухом можно сразу указать файл динамической библиотеки .so. В наших линуксовых сборках создаются только они. При этом статическая не нужна, линковщик подцепит все сам автоматом. При работе с MinGW под виндой одновременно с .dll нужно создать мелкий .a, который содержит информацию об импорте-экспорте. Это касается библиотек wxwidgets и common.

Статическая либа engine.a нужна, чтобы высвечивать как можно меньше ценного расчетного функционала и хитростей его реализации. Есть минимально необходимый API и все.

0

Сообщение от steevis 3. Основной расчетный движок выполняется в виде статической библиотеки,

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

Для UI - тем более. С wxWidgets работал лишь в одном проекте, и то "вскользь", поэтому на примере Qt. Приложение крутит событийный цикл объекта QApplication, который везде доступен через глобальную переменную qApp. Статическая линковка означает что этот объект будет в плагине, работать с хостом это конечно не будет. Нужно линковать динамически, причем указать Qt что она используется из плагина, такая опция есть (во всяком случае была).

Если же Вы придаете слову "статический" какой-то другой смысл, то извольте пояснить какой, иначе ответить Вам просто нечего. Какие проблемы с нормальной, динамической линовкой?

0