Организация plug-in'нной системы

[CityAceE]

Кто-нибудь может пояснить как организуется система plug-in'ов?

Поясню, что я имею ввиду. Вот, допустим, решил я написать какую-то программу (просмотрщик, проигрыватель, коммандер и т.д.) и мне хочется что бы программа была максимально простой и вместе с тем максимально универсальной. Универсальность должна достигаться плагинами. Чтобы не автор, а посторонние люди могли сами писать плагины, расширяющие функциональность программы....

Как правильно организовать программу чтобы она могла понимать плагины? Есть стандарты на это дело?

Павел Кисляк в своём Ral Commander'е все сделал по правилам или он придумал что-то своё?

Разложите, пожалуйста, по полочкам, кто знает. Уверен, что ответы на этот вопрос окажутся полезными не только мне.

[Advertiser]

[Vladimir Kladov]

стандарты устанавливает тот, кто пишет прогу, поддерживающие плагины. Пример: мой эмулятор (EmuZWin). Немного до сих пор нашлось людей, которые бы использовали эту возможность - для реализации своих плагинов. (1, ха). В винде плагин - это dll, которая 1. как-то опознается центральной программой (способов много, например - dll лежит в нужной папке, или у нее расширение изменено, или у нее есть особая точка входа) 2. имеет определенный набор экспортируемых процедур (э, да - функций тоже), часть из которых могут быть опциональны. Вот и все стандарты.

[SMT]

бывают ещё плагины в виде отдельных EXE. но наибольшую поддержку у плагинописателей находят скриптовые плагины (напр., браузер maxthon поддерживает все 3 вида: exe, dll, js/vbs. но больше всего написано js)

ps. кажись, офтопик пошёл. раздел-то - программирование на спектруме!

[captain cobalt]

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

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

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

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

Достоинства:
-- Таблицу адресов можно очень просто автоматически формировать пользуясь уже имеющимися трансляторами ассемблера

Недостатки:
-- Замедление исполнения. Каждый вызов требует обращения к таблице.
-- Раздувание модуля. Дополнительный код для обращения к таблице занимает память.
-- Сама таблица тоже занимает память и её нельзя освободить.
-- Потенциально меньшая гибкость. Адрес таблицы не должен меняться от версии к версии.

[SMT]

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

[Kurles]

ps. кажись, офтопик пошёл. раздел-то - программирование на спектруме!

Человек-то как раз про спековское программирование спрашивал. Кстати, вопрос действительно интересный...

[SfS]

Вопрос по сути можно озаглавить так: "Организация интерфейса между программными модулями".

На спеке стандатртов на динамические библиотеки (как впрочем и почти ни на что с программной стороны) нету.

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

По сути - любой подгружаемый плагин должен:

1. Быть идентифицирован программой как плагин (скажем по сигнатуре в начале файла).
2. Инициализирован какимто образом. Скорее всего плагину должны быть переданы адреса какогото блока данных, через который осуществляется взаимодействие, а от плагина должны быть получены точки входа в его процедуры.
3. Собственно взаимодействие программы с плагином в процессе ее работы. Тут все просто - просто программа, осуществляя какое-либо действие должна будет (до него, после или по какомуто условию) вызвать одну из процедур плагина по полученной при инициализации точке входа.

Очень трудно оговаривать систему плагинов в общем виде. Для каждой отдельной программы надо четко определить что и как можно расширять плагинами, а что должно оставаться неизменным. Конкретики надо.

[newart]

Очень трудно оговаривать систему плагинов в общем виде. Для каждой отдельной программы надо четко определить что и как можно расширять плагинами, а что должно оставаться неизменным. Конкретики надо.

Именно, в томже RC например легко можно было написать текстовый вьювер, плеер, конвертор картинок...
А вот сделать поддержку CD оказалось почти нереальным, пришлось бы делать патч кода.
Я написал под rc 3 модуля, и по правде делал это через силу, было жутко неудбно. Вот чего небыло в RC так это выгрузки модулей.

[acidrain]

Я написал под rc 3 модуля, и по правде делал это через силу, было жутко неудбно. Вот чего небыло в RC так это выгрузки модулей.

Скорее всего, этот вопрос можно напрямую адресовать тебе. Ведь у тебя есть опыт написания по RC, так что и как там организованно? Как все это дело работает?
Например, на амиге используется ARexx - скриптовый язык (родственник rexx'а), что практически является стандартом для плагинов... Но есть и другие способы при программировании на амиге.
Хочу все знать про спек. =)

[acidrain]

Хочу все знать про спек.

Так что, никто ничего не знает??? Меня порой удивляет пассивность людская. =)