Важная информация

User Tag List

Показано с 1 по 10 из 10

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

  1. #1
    Administrator Аватар для CityAceE
    Регистрация
    13.01.2005
    Адрес
    г. Владивосток
    Сообщений
    2,998
    Благодарностей: 1285
    Записей в дневнике
    5
    Mentioned
    5 Post(s)
    Tagged
    0 Thread(s)

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

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

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

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

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

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

  2. #1
    С любовью к вам, Yandex.Direct
    Размещение рекламы на форуме способствует его дальнейшему развитию

  3. #2
    Master Аватар для Vladimir Kladov
    Регистрация
    09.02.2005
    Адрес
    Новосибирск
    Сообщений
    933
    Благодарностей: 29
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  4. #3
    Veteran Аватар для SMT
    Регистрация
    16.01.2005
    Адрес
    Бобруйск
    Сообщений
    1,267
    Благодарностей: 30
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

  5. #4
    Activist Аватар для captain cobalt
    Регистрация
    13.03.2005
    Адрес
    Пермь
    Сообщений
    294
    Благодарностей: 4
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию Динамическая компоновка рулит

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

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

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

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

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

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

  6. #5
    Veteran Аватар для SMT
    Регистрация
    16.01.2005
    Адрес
    Бобруйск
    Сообщений
    1,267
    Благодарностей: 30
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  7. #6
    Member Аватар для Kurles
    Регистрация
    17.01.2005
    Адрес
    Cherepovets
    Сообщений
    121
    Благодарностей: 11
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от SMT
    ps. кажись, офтопик пошёл. раздел-то - программирование на спектруме!
    Человек-то как раз про спековское программирование спрашивал. Кстати, вопрос действительно интересный...

  8. #7
    Master
    Регистрация
    27.01.2005
    Сообщений
    527
    Благодарностей: 272
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

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

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

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

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

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

  9. #8
    Guru Аватар для newart
    Регистрация
    19.01.2005
    Адрес
    Санкт-Петербург
    Сообщений
    10,947
    Благодарностей: 1520
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

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

  10. #9
    Activist Аватар для acidrain
    Регистрация
    01.03.2005
    Адрес
    Russia, Krasnodar
    Сообщений
    433
    Благодарностей: 1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от newart
    Я написал под rc 3 модуля, и по правде делал это через силу, было жутко неудбно. Вот чего небыло в RC так это выгрузки модулей.
    Скорее всего, этот вопрос можно напрямую адресовать тебе. Ведь у тебя есть опыт написания по RC, так что и как там организованно? Как все это дело работает?
    Например, на амиге используется ARexx - скриптовый язык (родственник rexx'а), что практически является стандартом для плагинов... Но есть и другие способы при программировании на амиге.
    Хочу все знать про спек. =)
    http://amigasc.nm.ru

    Free coder and hardwareman
    Amiga addicted

  11. #10
    Activist Аватар для acidrain
    Регистрация
    01.03.2005
    Адрес
    Russia, Krasnodar
    Сообщений
    433
    Благодарностей: 1
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    По умолчанию

    Цитата Сообщение от acidrain
    Хочу все знать про спек.
    Так что, никто ничего не знает??? Меня порой удивляет пассивность людская. =)
    http://amigasc.nm.ru

    Free coder and hardwareman
    Amiga addicted

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Похожие темы

  1. Описание системы команд - давайте централизуем ;)
    от Alex/AT в разделе Программирование
    Ответов: 43
    Последнее: 09.07.2005, 21:11
  2. Инициализация системы
    от breeze в разделе Программирование
    Ответов: 13
    Последнее: 24.03.2005, 10:03

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •