OberonCore

Чтобы "впрыснуть", Вам придётся явно указать IMPORT SYSTEM. И Ваш модуль будут внимательно изучать, прежде чем начать использовать

Но ведь можно сделать "впрыск" иначе: написать программу с кучей мусорного кода в одной из процедур, далее "занопить" его и писать, что в голову взбредёт, уже в самом ocf-файле с помощью HIEW =)


Но ведь по сравнению с разработкой компилятора и загрузчика/среды для OCF-файлов создание среды с некоторыми "рюшечками" (пусть минимальными) - это не так сложно. Я не согласен с категоричным тоном высказываний w0nder (свою правоту можно доказывать более культурными методами), но он правильно говорит, что среда излишне аскетична. От себя добавлю - ещё и документации бы побольше. Turbo Pascal документирован значительно лучше...


А документация на формат OCF есть в общем доступе или это закрытая информация? Там x86 код или байт-код?

Спецификация всех форматов ББ есть в стандартной поставке, в каталоге Dev/Spec.
Там - x86-код, метаинформация и символьная информация.

Это было бы весьма полезным. А то обсуждение бинарников BlackBox пока на "крутые разборки" никак не тянет


Спецификацию нашёл, она оформлена с помощью какой-то очень странной нотации и почти не поясняет смысл того или иного поля. С заголовком разобрался (написал сишную структуру и разобрал по составу), с метаинформацией и релокейшенами всё сложнее. Какой модуль выполняет загрузку этих ocf-ок?
Теперь у меня стойкое ощущение, что для среды BlackBox модули можно делать хоть на FASM, хоть на Си . Был бы линковщик.

Нотация - обычная НФБ-грамматика вроде бы...
А загрузку и связывание выполняет модуль StdLoader.

Теперь вижу... Погулял по тексту модулей, потихоньку начинаю понимать строение ocf-файла. ИМХО, упрощённый вариант PE. Первые впечатления от исходников среды: идея разбиения на кучу маленьких модулей прекрасна - текст становится значительно более понятным. Но исходники очень мало комментированы. Приходилось видеть кусочки кода FreeDOS и инструментов пользователя из поставки Open Watcom C, там "комментов" ощутимо больше. Я не собираюсь создавать собственную версию BlackBox, но для привлечения разработчиков к порту под Linux (как 32, так 64 - битный) определённо нужна документация по устройству ядра системы.

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

А по поводу кода - за два года работы и сопровождения ББ я оценил особенность Оберона - язык практически не даёт мест для "произвольного выбора" (когда можно написать и так, и так - хоть монетку кидай). Поэтому, если следовать правилам оформления, исходники получаются совершенно единообразными - и в алгоритмических конструкциях никакой "личностности" не остаётся. Уровнем повыше - конечно, да. Например, Framework делали Пфистер, Шиперски и Век, а низкоуровневые модули - другие разработчики, и различия в стиле сразу видны (в низкоуровневых модулях недостаточно расслоили функционал по уровням).

Интересно, через какое время Вы начнёте ощущать модуль не как просто отдельный файл с исходным кодом... а как... как модуль

Я его сейчас ощущаю примерно как нечто, весьма сходное с DLL. По крайней мере, модуль вполне попадает под определение Dynamic Linked Library.


Блок описания действительно был бы очень неплох. Я и не предлагал комментировать всё, а хотя бы перед процедурой кратко писать её назначении, а также документировать структуры и смысл глобальных переменных (ну те, которые на уровне модуля). И в длинных кусках кодах иногда бывает полезным разделить комментариями смысловые блоки.

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


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

Не забудьте в своих прогулках по среде воспользоваться составленной документацией на Kernel:
http://wiki.oberoncore.ru/index.php/BlackBox:Kernel

По поводу модуля... Ну, DLL - это с какой-то стороны... Вот возьмите в руки жёсткий диск и шлейф к нему. Подержите в руках. Почувствуйте его реальность и осязаемость, замкнутость в себе и фиксированность компактного интерфейса. Вот в модульном языке модули являются такими же чуть ли не физически осязаемыми блоками архитектуры. Хоть на зуб можно пробовать Шутки шутками, но субъективно ощущается именно так.

Предлагая любые измения формата OCF необходимо в обязательном порядке сохранить возможность распознавать и правильно обрабатывать оригинальный OCF. А что конкретно не устраивает сейчас?

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

А зачем Вам так ассемблер понадобился?

Если очень нужно IMPORT SYSTEM, тег PROCEDURE [code] - и вперёд
Не такое простое занятие, конечно, прямо в машкоде.

Я под Линуксом написал скрипт asm.h:

as -o $1.o $1
ld -o $1.bin --oformat binary $1.o
rm $1.o

Скрипт натравливается на исходник с ассемблерными командами, а на выходе - чистый машкод без заголовков.
Просто брать и вставлять.
Правда, под Линуксом формат ассемблера другой, обратный порядок аргументов команды, префиксы % перед именами регистров, у каждой команды постфикс размера аргументов (movl, addl). Но это удобней интелевской нотации.

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


А как же релокейшены? Насколько я понял, адрес загрузки модуля не фиксирован.

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

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

А что касается абстрагирования от ОС, то в рамках одного оборудования при соответственно сделанной архитектуре даже перекомпиляция большинства модулей рантайма становится не нужной.

Я кажется догадываюсь зачем. Да ScrollLock и сам проговорился вначале.
Придется свои смещения обрабатывать самому.

В таком случае можно довольно легко получить значение IP (т.е. адреса, по которому идёт выполнение). Это немного похоже на хак, но работает:

Интересно что всё-таки дальше планируете? Относительно заявленной темы.

Ну дык и так ясно - что! Безобразия и излишества всякие...