Загрузка библиотек

Internal structure and you change requests/suggestions
  • Краткий итог обсуждения

    Сначала вопросы 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 Мб будет неплохим вариантом - ядро пропустит создание нулевой таблицы страниц.
  • -- Порядок поиска DLL --

    DLL - общеизвестное название, не вижу смысла переименовывать их в lib. Я также за то, чтобы дать исполняемым файлам какое-нибудь расширение, напр. "exe".

    Системные папки могут определяться:
    - через переменную окружения (%sys%, %dll%, ..), тогда обращение к файлу будет вида "%sys%\license.txt".
    - функция ПолучитьПуть(Тип), где Тип (dd) = "sys ", "dll ", ..; возвращается путь. Для обращения потребуется: ПолучитьПуть("sys")+"license.txt"
    - фиксовые пути - нежелательно

    Поиск DLL только в текущей папке программы и %dll%.

    Если DLL написаны правильно, то можно не загружать их дважды, т.е. запуске приложения DLL загружается и количество использований устнавливается в 1, при запуске других приложений количество использований инкрементируется (+1), при закрытии - декрементируется (-1). Когда количество использований станет равным 0, DLL выгружается. В таком случае поиск будет:
    1. загруженные DLL из папок программ
    2. папка программы
    3. загруженные DLL из %dll%
    4. %dll%
  • Формат должен быть обычным PE exe, чтобы цепочка действий для получения работоспособной программы с любым компилятором была как можно проще. Поддержка урезанного заголовка для маленьких программ и автосборки готовых на дополнительных действия - приятный бонус, но а) необязательный, б) основной формат - PE, заголовок должен получаться из уже готового PE без всяких махинаций со скриптами ld, в) вообще можно добавить потом, потому что код загрузки будет отличаться только тем, по каким смещениям он читает поля заголовка.

    Порядок поиска: заглянуть в /rd дёшево, так что первым делом стоит просмотреть /rd/1/lib. Дальше можно ограничиться /kolibri/lib - по крайней мере, для начала, с путём к exe'шнику придётся возиться.
    Сделаем мир лучше!
  • Почему считаешь нужным ускорять процесс компиляции программы, а не её запуска? Почему предпочтение отдано формату PE, а не COFF, ELF или каким-либо другим?
  • По количеству компиляторов. Откуда взялось противопоставление времени компиляции и времени запуска? Какое отношение формат имеет ко времени компиляции?
    Сделаем мир лучше!
  • > По количеству компиляторов.

    Можно увидеть исходные данных статистического исследования на основании которого было сделано это заключение? Я напр. не знаю ни одного компилятора, который бы умел создавать PE, но не умел COFF.

    > Откуда взялось противопоставление времени компиляции и времени запуска? Какое отношение формат имеет ко времени компиляции?

    Формат влияет на время запуска, так файл существующего формата (первые N байт в начале плоского файла) можно запустить быстрее, чем PE/ELF. И вопрос как раз был почему ты отдаёшь приоритет времени компиляции в ущерб времени запуска?

    CleverMouse: читайте теорию до просветления, пока не поймёте, в чём отличие PE от COFF и какой из них приспособлен для компиляции нетривиальных проектов в один исполняемый файл. До тех пор вы забанены.
  • CleverMouse
    Если основным форматом сделать PE, ассемблерщики будут поминать нас тихими, незлобивыми словами. Как им путь к экзешнику и командную строку получать ?
  • Пусть загрузчик запихнёт два указателя в стек перед вызовом entry point, если так уж не хочется писать API загрузчика.
    Сделаем мир лучше!
  • Есть решение проще. Записать в регистры. Странно, что Вилле не додумался и мы до сих пор не использовали.
  • Serge wrote:Есть решение проще. Записать в регистры. Странно, что Вилле не додумался и мы до сих пор не использовали.
    О! Вот это идея! Тогда получится, что точка входа -- это как бы процедура с параметрами? Элегантно.

    Раз уж PE, как понимаю, избежать не удастся, есть два предложения:
    • Наряду с обычными PE позволять начинать файл сразу c PE-секции -- 'PE', 0, 0, чтобы можно без DOS-заглушки. Сэкономит минимум 64 байта, а со стандартыми заглушками -- 128 байт и больше.
    • Придумать константу IMAGE_SUBSYSTEM_KOLIBRI, либо в поля MajorVersion.MinorVersion писать что-то свое (0.7 или 0.8), чтобы Windows выдавала, что эти файлы не являются приложениями Win32.
  • Кстати да, будут загружать PE экзешники под windows со всеми вытекающими. И получать отсутствующие длл. И наоборот само собой.
  • Fanatic wrote:Наряду с обычными PE позволять начинать файл сразу c PE-секции -- 'PE', 0, 0, чтобы можно без DOS-заглушки. Сэкономит минимум 64 байта, а со стандартыми заглушками -- 128 байт и больше.
    Это рюшечки. PE-заголовок можно сокращать, но сначала нужно сделать наконец поддержку PE - потом уже будет видно, какие поля загрузчик действительно использует, а какие просто занимают место.
    Сделаем мир лучше!
  • Serge wrote:1. PE упрощает разработку драйверов на HLL. Создать обычным путём COFF драйвер из многофайлового проекта на Си очень проблематично.
    2. Сгенерированный HLL компилятором COFF раздут из-за отладочной информации.
    3. Ассемблерные PE и COFF драйвера примерно одинакового размера но COFF сложнее в загрузке.
    4. PE загружается явно, с передачей командной строки.
    4. Есть намерение в перспективе полностью перейти от COFF к PE.

    Резюмируя всё, у COFF нет преимуществ перед PE нет, зато есть серьёзные недостатки. COFF - формат объектного файла, для исполняемого он плох.
  • Ассемблерные PE и COFF драйвера примерно одинакового размера но COFF сложнее в загрузке.
    Ну PE, конечно, легче грузить http://websvn.kolibrios.org/blame.php?r ... 21#line-51 :lol:
    Только забыли положить рядом Си-шный исходник. А то не каждый сразу поймёт, что там за L20, L30, ... и что там за "магические" смещения такие.
    Ладно бы там ещё http://websvn.kolibrios.org/filedetails ... c&peg=4421 такое с полпинка не напишешь.

    И я не хочу сказать, что си — это плохо, но не нужно извращаться, а надо нормально прилинковывать.
    Если уж что-то на asm сделать трудно, то почему бы и на си тогда не сделать.
  • Who is online

    Users browsing this forum: Ahrefs [Bot] and 10 guests