Краткий итог обсуждения
Сначала вопросы 2008 года.
1. Где хранить многотонные DLL ? Усилиями Марата вопрос решился - /kolibrios/lib
2. Порядок поиска DLL. Сейчас поиск ведётся только в /kolibrios/lib
Можно искать сначала в каталоге исполняемого файла, потом /rd/1/lib, потом /kolibrios/lib, но это замедлит загрузку приложения. Ещё можно прописать пути в заголовке приложения (всё эльфистие и эльфистие) или сделать там набор флагов для стандартных путей. Или ввести переменные окружения (ещё одна большая тема) где будут прописаны пути поиска.
Варианты загрузки.
В то время я активно продвигал PE в качестве формата исполняемых файлов. Тогда это представлялось мне самым простым способом упростить и автоматизировать загрузку DLL. На эту тему было много споров с
diamond-ом, которому не нравились лишние байты в заголовке PE. В результате этих споров договорились до создания своего упрощённого варианта PE, на чём дело и было успешно похоронено.
Внезапно выяснилось, что
скрипты LD мощное средство, если уметь ими пользоваться, а макросы fasm могут вообще всё, что угодно. Для автоматической линковки PE DLL достаточно таблицы импорта в исполняемом файле. И ld и fasm это условие выполняют. Примеры на fasm, использующие PE DLL:
раз,
два
В текущем варианте динамический компоновщик является частью libc. Для программ на Си это очевидное решение, для остальных нет. Если внедрять
новый формат заголовка, я уберу компоновщик из libc и перепишу его на ассемблер с неизбежными ошибками
. Ядро создаст образ приложения и скопирует компоновщик в вершину юзерспейса по фиксированному адресу, остальную работу он выполнит сам. Если делать поддержку PE EXE схема загрузки будет примерно такой же, но в этом случае я не вижу смысла делать новый заголовок. Зачем лишние сущности ?
Вот и оставшиеся вопросы:
1. Порядок поиска DLL.
2. Формат исполняемых фалов - новый заголовок или pe exe.
И дополнение по новому заголовку. Лучше не использовать 0 в качестве базового адреса. 4 Мб будет неплохим вариантом - ядро пропустит создание нулевой таблицы страниц.