Менеджер DLL в MeOS

Discussing libraries simplifying applications development
  • а зачем поддержка библиотек в ядре?
    в FASM можно скомпилировать:

    Code: Select all

    use32
    ord 0x0
    dd 3 ;- число функций
    dd func1
    dd func2
    dd func3
    func1:
    ...
    ret
    func2:
    ...
    ret
    func3:
    ...
    ret
    грузим её в память с помощью менеджера памяти, получаем смещение каждой функции и делаем вызовы
  • >грузим её в память с помощью менеджера памяти, получаем смещение каждой функции и делаем вызовы.

    Вот как раз на этом пункте все дело и встало.Нужно совершенствовать менеджер памяти для этого дела.А в менеджере памяти разбирается только сам автор - Халявин Андрей.
  • Да не на этом всё стало. Как раз-таки в менеджер памяти добавить несложно.
    1. Грузить надо по какому-то адресу, и вряд ли это адрес 0, как для приложений. А тогда придётся либо требовать загрузку по фиксированному адресу (что не есть хорошо), либо писать полностью позиционно-независимые DLL (и по коду, что несложно, и по данным, что гораздо хуже), либо мучиться с перемещаемыми элементами (relocations), что потребует как мимнмум разработки формата DLL. А ведь нужно ещё учитывать, что в разные процессы DLL может загружаться по разным адресам...
    2. Грузить DLL надо из каких-то файлов. А где эти файлы хранить? Кроме как на рамдиске - нехорошо, поскольку FAT32-винта может и не быть (дискета - не вариант), а на рамдиске и так куча файлов (папки не поддерживаются).
    3. Помимо явной загрузки DLL бывает ещё неявная - кодом загрузки программ, которая в большинстве случаев удобнее: в exe-шник помещается информация о том, что импортируются такие-то функции таких-то библиотек, в результате к началу исполнения программы без каких-либо системных вызовов адреса всех функций уже "на месте". А для этого нужно уже развивать формат exe-шников.
    Ушёл к умным, знающим и культурным людям.
  • diamond
    Для меня сделать поддержку папок на RD не составляет большой проблемы (ведь для дискеты я же сделал, хотя исходный код был от RD драйвера).
    Но меня мучает другой вопрос - мы вроде как собирались отказываться от RD (именно по этому я приостановил ковыряние с Fat12). Да и к тому же много библиотек в него не запихнешь, место ограничено. Как быть в этом случае?
  • Mario79
    Это я перечислил проблемы, пришедшие мне в голову. Предыдущий пост следует считать ещё одной проблемой, а к скобке в конце пункта 2 следует относиться как к исправимому недостатку (хотя если отказываться от рамдиска, это автоматически перестаёт быть недостатком). А писать код, пока не принято решение о дальнейшей судьбе рамдиска, действительно не стоит.
    Ушёл к умным, знающим и культурным людям.
  • Для меня сделать поддержку папок на RD не составляет большой проблемы (ведь для дискеты я же сделал, хотя исходный код был от RD драйвера).
    Но меня мучает другой вопрос - мы вроде как собирались отказываться от RD (именно по этому я приостановил ковыряние с Fat12). Да и к тому же много библиотек в него не запихнешь, место ограничено. Как быть в этом случае?
    Неееет. Рам диск нужен. Я хотел в дальнейшем предложить его использовать как некое подобие реестра и для хранения стандартных элементов системы (конфиги, установленные драйвера, необходимые для системы проги, стандартные иконки), но для этого, как раз нехватает поддержки папок.
    А в связи с повсеместной мобилизацией осей, рам диск используется почти везде. В любом случае, в дальнейшем, может возникнуть необходимость в поддержке рам диска, особенно если комп без винта, а загрузка и работа системы выполняется через флэш'ку.
    Выношу вердикт - RAM-диску быть!
  • Я тоже за RD, но дело не в этом. Можно сделать реестр библиотек, где указывается местонахождение билиотеки.
    Для библиотеки должна быть точка входа, где в качестве параметра имеется ссылка на адрес для данных. В точке входа выделяется память, и идёт работа через смещения, а для каждой процедуры указывать этот адрес.
  • Я начал переписывать менеджер памяти. Пробный образец уже работает. Можно будет выделять память в адресном пр-ве
    ядра и грузить туда драйверы и библиотеки. Для библиотек можно использовать COFF формат - он стандартен, хорошо описан и
    главное поддерживается FASM. Там есть таблицы релокаций, так что программы можно будет грузить по любому адресу.
  • Можно Ярековский ld-dll вспомнить и довести до ума
  • Serge
    Переписывать? А как же старый менеджер памяти? Может быть, лучше расширить его функциональность?
    Или у него есть принципиальные неустранимые недостатки?

    Хотелось бы побольше узнать о том, что, как и почему планируется сделать.
  • Иван Поддубный

    Кажется ты писал, что кроме автора никто не знает как он работает. Я честно пытался разобраться в его работе и кое-что понял. Например функция выделения физической выделяет всего 24 блока ( если верить исходникам), блок выделяется не в области приложения, где он нужен больше всего, а где-то в параллельной вселенной и доступ к нему осуществляется через подфункции типа get_buffer и set_buffer функ. 68. Это больше похоже на работу с файлами. Память из диапазона 0х0 - 0х00100 000 (первые 16 мб) также отображаются на адреса 0хС000 0000 (для чего ???). Некоторые программы используют старые флаги mem_size = 0x300000 например 5 килобайтный cmd при загрузке запрашивает 3 мегабайта памяти и получает их!
    Я хочу хочу сделать менеджер памяти который будет решать все эти проблемы. Напрмер при загрузке программа будет получать физической памяти ровно столько сколько ей нужно, а не сколько указано в заголовке. При этом сохранится совместимость с нынешними программами, а необходимая физ. память будет выделятся только тогда, когда программа к ней реально обращается. Можно будет отображать видеопамять в адресное пр-во приложения и получать к ней прямой доступ не через селектор gs а обычным путем. Появится возможность эмулировать LFB для старых видеокарт с банками памяти - отпадет необходимость в разных функциях рисования для банков и LFB.
    Можно будет использовать глобальные и большие 4 мБ страницы памяти на тех процессорах, где есть
    такая возможность

    Для выделения памяти в ядре будет функция kernel_alloc, выделяющая и резервирующая память страничными блоками и user_alloc для приложений. Наконец для приложений портирую стандартную библиотечную malloc.
    Сейчас ядро с новым менеджером страничной памяти грузится нормально и работают все программы
    не использующие read/write_process_memory и IPC. Эти программы вызывают страничные нарушения, зависают и убиваются обычным образом. Больше всего пострадал отладчик, но скоро я напишу все необходимые для его работы функции. Как только будут готовы
    kernel_alloc, user_alloc,
    read/write_process_memory IPC

    сделаю подробное описание всех изменений.

    Последнее.
    Пока код не устоялся надо определиться с распределением памяти. Например я установил адресное пр-во приложений в 2 гигабайта из них 128 мегабайт адресов зарезервировано под ядро. Надо окончательно определится с размероми памяти ядра и памяти приложений.
  • Serge
    68ая функция предназначена для выделения непрерывного блока физической памяти. Это не malloc/free!!! Непрерывная физическая память нужна для работы с железом через DMA.
    Да, выделяется не больше 24 блоков. Но пока этого достаточно.
    Ещё раз подчеркну: менеджер физической памяти и менеджер памяти - это совершенно различные вещи! Не надо их путать.

    Что касается менеджера памяти, то я сейчас пытаюсь в нём разобраться. Хотелось бы ввести для приложений malloc и free. Но для этого придется убрать функцию 64...
  • Ядро отображается дважды из-за того, что планировалось перенести ядро в верхние адреса и перейти от сегментно-страничной модели памяти к чисто страничной.
    Селектор gs, по-моему, никому не мешает.

    Распределение памяти в КолибриОС:
    Image
  • http://shade.msu.ru/~msu-se/memtest.7z - менеджер памяти для приложений. По-видимому это лучшее, чего можно добиться при существующем ядре.
    На счет нормального alloc'a и free - нужно реализовывать структуру почти уровновешенного дерева, иначе поиск пустого блока в адресном пространстве может стать слишком долгим. Конечно простой список для начала сойдет.
    PS Serg На сколько я понимаю тебе придется разбираться с файлами mem.inc и newprocess.inc, а файл memmanager.inc тебе будет нужен только в качестве справки по доступным функциям менеджера памяти. Как автору большей части кода в этих файлах можешь посылать вопросы в приват или по e-mail (он в исходниках есть).
    PSPS Для удобства добавления изменений в ядро следует внимательно следить за выравниванием - оно не должно сбиваться по всему файлу (такое бывает, когда используются редакторы с разными размерами tab size). Вообще tab'ов в исходниках быть не должно - они порождают слишком много проблем.
  • Who is online

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