Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 28 мар 2024, 17:03

Часовой пояс: UTC + 2 часа




Начать новую тему Ответить на тему  [ Сообщений: 2 ] 
Автор Сообщение
СообщениеДобавлено: 15 ноя 2013, 13:46 
Не в сети

Сообщения: 116
Откуда: Каменск-Уральский
В файле Program1.link указана строка
S.Atan писал(а):
Код: "OBERON"
  1. MODULES
  2. Kernel, Program1


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


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: Часть третья. Быть или не быть?
СообщениеДобавлено: 15 ноя 2013, 23:53 
Не в сети
Аватара пользователя

Сообщения: 1019
Откуда: Днепропетровская обл.
Очень хороший вопрос. Давайте разберёмся как устроена динамическая модульность в системе ETH Oberon (а заодно и в ETH PlugIn Oberon for Windows) и как её можно использовать с помощью OPCL.

Закономерно, что не все модули ETH Oberon являются динамическими: ведь для того, чтобы загрузить модуль (из файла в память) нужно как минимум уже иметь средства для распределения памяти и работы с файлами. Поэтому модули Kernel и Files быть динамическими не могут и не должны, как и некоторые другие модули. Загрузчик ОС (или подсистема исполнения Windows PE - Portable Executables) загружает такие модули в память своими личными низкоуровневыми средствами (средствами вышележащей ОС или же, например, путём вызова прерываний BIOS или как-то ещё). Вобщем, примем как факт, что часть модулей спроектированы не для динамической загрузки и уже находятся в нашем распоряжении (в случае с Windows, которая не имеет в своём составе рантаймов для поддержки Оберон-окружения, такие модули могут быть вкомпилированы в целевой исполняемый файл).

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

Код: "OBERON"
  1. MODULE Modules; (** portable, except where noted *)
  2.  
  3. (**
  4.  The Modules module implements the dynamic module loader of the Oberon system.
  5.  It is responsible for loading and freeing modules.
  6. *)
  7.  
  8. IMPORT Kernel32, Kernel, Registry, FileDir, Files, SYSTEM;
Очевидно, все импортированные здесь модули должны быть доступны ДО загрузки любого динамического модуля.

Вот эта процедура:
Код: "OBERON"
  1. (** Returns a handle to an already loaded module,
  2.  or if not loaded, loads the module and all its imported modules. *)
  3.  
  4. PROCEDURE ThisMod* (name: ARRAY OF CHAR): Module;
получает на вход имя загружаемого модуля и возвращает указатель на дескриптор модуля.

Процедура:
Код: "OBERON"
  1. (** Free a module from memory. Only modules with no clients can be freed.
  2.  The all flag requests that all imported modules should be freed too (i.e. a recursive call to Free). *)
  3.  
  4. PROCEDURE Free* (name: ARRAY OF CHAR; all: BOOLEAN);
выгружает указанный модуль (и все зависимые от него, если all = TRUE).

Осталось понять как этим пользоваться. Я нашёл такой пример использования динамической загрузки в модуле ETHOberon/Src/Printer.Mod:
Код: "OBERON"
  1. Mod := Modules.ThisMod("WinPrinter"); (* Загружаем динамически модуль WinPrinter *)
  2. IF Modules.res = 0 THEN (* Если успешно загрузился, то: *)
  3. Cmd := Modules.ThisCommand(Mod, "Install"); (* Ищем в нём команду
  4. (процедуру без параметров) установки "Install" *)
  5. IF Modules.res = 0 THEN (* Если она там присутствует, то: *)
  6. Cmd() (* Запустим её *)
  7. END
  8. END
В идеале хорошо бы состряпать минимальный примерчик, который бы показывал динамическую модульность в действии, однако, Len, оставляю это на Ваше усмотрение. В мире Оберона мало готовых решений, тем он меня, например, и привлекает.

Теперь далее. Я не рыл очень уж досконально потроха ETH Oberon, но полагаю, что в какой-то момент с помощью Modules.ThisMod загружается динамический инициализатор Оберон-системы, и он уже в свою очередь пользуется для загрузки/выгрузки модулей только этим механизмом (т.е. все последующие модули уже динамические).

Теперь немножко о том как реализовывать свои плагины. Пишете модули с одинаковым интерфейсом. Папочкой для них будет абстрактный модуль-контейнер, экспортирующий виртуальную запись, в которой методами будут указатели. Реализации этого интерфейса будут импортировать контейнер (но не наоборот!). Инсталлятор реализаций будет инициализировать эту запись (подключать в абстрактный слот контейнера нужную реализацию, при необходимости подгружая соответствующий модуль). Совместимость интерфейсов гарантируется совместимостью типов виртуальной и реализованной записи. Если нужно расширение, унаследуем от этой записи и расширим её дополнительным функционалом. Примеры смотрите в BlackBox'е (SystemFiles и HostFiles, SystemDialog и HostDialog, и т.д.).

В качестве теоретического материала советую главу "6. Загрузчик модулей" из книги "Разработка операционной системы и компилятора. Проект Oberon", стр. 183-197.


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 2 ] 

Часовой пояс: UTC + 2 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


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

Найти:
Перейти:  
cron
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club