История изменений

Исходя из того, что я вычитал (страница 32) и из твоей ссылки на StdLoader вырисовывается картина, что из модуля грузятся только смещения, а не текстовые символы, как в DLL/SO.

Нет, там производится подстановка адресов импортированных по имени символов в места их использования также как в ELF с -fno-pic. Для импортированных модулей с другими адресами символов сохраняется бинарная совместимость. Собственно процесс чтения таблицы импорта и релокации происходит здесь. Первый цикл идёт по списку импортированных модулей, второй цикл — по импортированным символам из модуля. Бинарный поиск символа в модуле по имени делает Kernel.ThisObject(imp.mod, name), imp.mod это заголовок загруженного модуля в памяти, содержащий указатель на таблицу экспорта. Далее делается вызов Fixup, который читает список релокаций и осуществляет запись адреса символа с возможным смещением в сегменты модуля. Используется сжатый формат релокаций: для одного и того же символа старое значение по адресу релокации указывает на следующий адрес релокации так что релокациии могут вообще не практически не занимать дополнительного места и храниться там, куда должны быть записаны адреса импортированных символов.

Если же софт open source, то ты можешь безо всяких модулей тупо скомпилировать всё в один блоб, а потом при необходимости делать инкрементальную компиляцию — зачем тут модули?

В Оберон системах можно динамически загружать и выгружать модули в рабочей системе без перезагрузки. Сделали изменения в коде модуля, скомпилировали, перезагрузили только этот модуль и будет использоваться новая версия модуля. Также в Оберон системах можно легко вызывать экспортированные процедуры модуля из GUI (в классическом Обероне средней кнопкой мыши по Модуль.Процедура, в BlackBox по нажатию объекта «коммандер» перед командой или оборачивание команды в ссылку/кнопку/пункт меню).

скомпилировать всё в один блоб

Ещё динамическая загрузка работает намного быстрее, чем статическая линковка. Компиляция и перезагрузка модуля занимает меньше пол секунды. Можно часто править и перезагружать модуль, будет сразу виден результат. Очень удобно по сравнению с C/C++.

Еще мне неясно, что эта BlackBox будет делать в ситуации, когда в системе нужно несколько разных версий одного и того же модуля.

Есть система рабочих директорий по типу virtualenv Питона. Можно использовать номер версии в имени модуля (например Display, Display2, Display3 из ETH Oberon), одинаковые символы в разных модулях не вызывают коллизий.

Исходя из того, что я вычитал (страница 32) и из твоей ссылки на StdLoader вырисовывается картина, что из модуля грузятся только смещения, а не текстовые символы, как в DLL/SO.

Нет, там производится подстановка адресов импортированных по имени символов в места их использования также как в ELF с -fno-pic. Для импортированных модулей с другими адресами символов сохраняется бинарная совместимость. Собственно процесс чтения таблицы импорта и релокации происходит здесь. Первый цикл идёт по списку импортированных модулей, второй цикл — по импортированным символам из модуля. Бинарный поиск символа в модуле по имени делает Kernel.ThisObject(imp.mod, name), imp.mod это заголовок загруженного модуля в памяти, содержащий указатель на таблицу экспорта. Далее делается вызов Fixup, который читает список релокаций и осуществляет запись адреса символа с возможным смещением в сегменты модуля. Используется сжатый формат релокаций: для одного и того же символа старое значение по адресу релокации указывает на следующий адрес релокации так что релокациии могут вообще не практически не занимать дополнительного места и храниться там, куда должны быть записаны адреса импортированных символов.

Если же софт open source, то ты можешь безо всяких модулей тупо скомпилировать всё в один блоб, а потом при необходимости делать инкрементальную компиляцию — зачем тут модули?

В Оберон системах можно динамически загружать и выгружать модули в рабочей системе без перезагрузки. Сделали изменения в коде модуля, скомпилировали, перезагрузили только этот модуль и будет использоваться новая версия модуля. Также в Оберон системах можно легко вызывать экспортированные процедуры модуля из GUI (в классическом Обероне средней кнопкой мыши по Модуль.Процедура, в BlackBox по нажатию объекта «коммандер» перед командой или оборачивание команды в ссылку/кнопку/пункт меню).

скомпилировать всё в один блоб

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

Еще мне неясно, что эта BlackBox будет делать в ситуации, когда в системе нужно несколько разных версий одного и того же модуля.

Есть система рабочих директорий по типу virtualenv Питона. Можно использовать номер версии в имени модуля (например Display, Display2, Display3 из ETH Oberon), одинаковые символы в разных модулях не вызывают коллизий.

Исходя из того, что я вычитал (страница 32) и из твоей ссылки на StdLoader вырисовывается картина, что из модуля грузятся только смещения, а не текстовые символы, как в DLL/SO.

Нет, там производится подстановка адресов импортированных по имени символов в места их использования также как в ELF с -fno-pic. Для импортированных модулей с другими адресами символов сохраняется бинарная совместимость. Собственно процесс чтения таблицы импорта и релокации происходит здесь. Первый цикл идёт по списку импортированных модулей, второй цикл — по импортированным символам из модуля. Бинарный поиск символа в модуле по имени делает Kernel.ThisObject(imp.mod, name), imp.mod это заголовок загруженного модуля в памяти, содержащий указатель на таблицу экспорта. Далее делается вызов Fixup, который читает список релокаций и осуществляет запись адреса символа с возможным смещением в сегменты модуля. Используется сжатый формат релокаций: для одного и того же символа старое значение по адресу релокации указывает на следующий адрес релокации так что релокациии могут вообще не практически не занимать дополнительного места и храниться там, куда должны быть записаны адреса импортированных символов.

Если же софт open source, то ты можешь безо всяких модулей тупо скомпилировать всё в один блоб, а потом при необходимости делать инкрементальную компиляцию — зачем тут модули?

В Оберон системах можно динамически загружать и выгружать модули в рабочей системе без перезагрузки. Сделали изменения в коде модуля, скомпилировали, перезагрузили только этот модуль и будет использоваться новая версия модуля. Также в Оберон системах можно легко вызывать экспортированные процедуры модуля из GUI (в классическом Обероне средней кнопкой мыши по Модуль.Процедура, в BlackBox по нажатию объекта «коммандер» перед командой или оборачивание команды в ссылку/кнопку/пункт меню).

Еще мне неясно, что эта BlackBox будет делать в ситуации, когда в системе нужно несколько разных версий одного и того же модуля.

Есть система рабочих директорий по типу virtualenv Питона. Можно использовать номер версии в имени модуля (например Display, Display2, Display3 из ETH Oberon), одинаковые символы в разных модулях не вызывают коллизий.