Менеджер DLL в MeOS

Discussing libraries simplifying applications development
  • Как говорил Mario79,главное что заметили :(
  • Victor,толькочто скачал твои наработки.Вовремя скачать неполучилось,так как в сети не каждый день бываю.А когда еще по учебе дел много(как сейчас),так еще реже в сети бываю.

    К сожелению неполучилось скомпилировать программы,так как требуется макрос debug2.inc ,а у меня его нет.

    Несложно заметить,что самый активный участник и программист,проверяющий новые наработки программистов и высказывающий своё мнение и пожелания - это Марат(Mario79).Остальные в большинстве случаев молчат.Мол типа,а нам без разницы - будет эта программа или её не будет.Я вот до сих пор незнаю - терпимый ли я делаю графический редактор(он пока недозавершен) или он народу ненравиться.Неактивный народ.
  • Выложил архив со включенным debug2.inc (думаю Майк не против). Ссылка выше.
  • Попробовал загрузить библиотеки.При этом я изменил дериктории(вместа рамдиска жесткий диск).Запустил программу,а библиотека не грузиться(на доске отладки написано NOT_LOAD).Посмотрел каким образом в коде загружаются библиотеки и увиде там новую 70-ю функцию.Но ведь эта функция на стадии внедрения.И насклько я понимаю,ядро с новой функцией доступно только разработчикам ядра.

    Или где-то выложено новой ядро ?
  • Лучше не изобретать свой собственный формат, а использовать уже существующий.
    Есть COFF, MS COFF, OMF32, ELF любой из форматов можно использовать. Там уже все есть и релокации и экспортируемые имена и таблицы символов и отладочная информация. А в нынешнем варианте библиотеки грузятся по фиксированным адресам и как решать проблему с релокациями без переделки FASM не вполне ясно. Наконец как сгенерировать такой длл файл компилятором ЯВУ, который об этом новом формате ничего не знает?
  • andrew_programmer wrote: где-то выложено новой ядро ?
    На SVN всегда самое новое ядро. С вопросами - к halyavin
    Vivat assembler et KolibriOS!
  • http://heavyiron.kolibrios.org/files/kernel.7z - последнее ядро ревизии 874
    Last edited by Heavyiron on Fri Oct 10, 2008 1:34 am, edited 3 times in total.
  • Serge,а я думал,что ответственность за релокацию ляжет на новый менеджер памяти.
  • Serge
    А зачем нам Колибри,если есть такой прекрасный виндовс?
    Конечно COFF может и лучше того что я пока сделал,но мне не хотелось бы просто его приспособить
    Насчёт релоков,сделаю прогу которая будет конвертировать из COFF в формат этих "недодлл" и не надо будет никаких особых яву.
    Ядра нового у меня нет. На эмуляторе диамонда всё тестил. Просто неохота потом париться с внедрением LFN.К тому же функция 70 мне больше понравилась чем 58 :)
    МП могут быть свои релокации,да и вообще свободная релокация не должна быть,имхо. МП может "релокировать" данные.
  • andrew_programmer
    Я только начал делать и это только первый вариант,который хоть что то может
    Насчёт харда не знаю. По идее не должно быть различий в работе. Главно в прогу путь правильный прописать
  • andrew_programmer wrote:Serge,а я думал,что ответственность за релокацию ляжет на новый менеджер памяти.
    Конечно, на него. Но менеджер памяти должен знать, какие символы релоцировать :)
    Vivat assembler et KolibriOS!
  • Victor,я прекрасно понимаю,что это первая программа и ты только еще начал её делать.
    Я ведь тоже в такой ситуации бывал.

    В настоящей Колибри мне неудалось загрузить библиотеки.Все также пишет E_NOT_LOAD.Причину незнаю.
  • Serge,а я думал,что ответственность за релокацию ляжет на новый менеджер памяти.
    Ребята, да вы чего ???. Менеджер памяти выделит память и укажет адрес и гарантирует что никакая другая программа в эту память не залезет. Настроить релокации - задача загрузчика. Пока в программах стоит org 0x6000 org 0x6400 и грузятся они по фиксированным адресам. Но главное не в этом. Я понимаю, что нельзя сделать всё сразу, но зачем создавать свой собственный уникальный формат? Это путь Майкрософт. Я не призываю использовать в обязательном порядке COFF или MS COFF есть разные форматы и есть из чего выбирать. Лучший вариант - формат который открыт, хорошо документирован и поддерживается большинством компиляторов.
  • Serge
    Тогда по другому скажу. Я не знаю как в текущем виде всё уместить в кофф. Пока в ядро поддержку длл никто не встраивал,а я не представляю как это сделать. Можно использовать немного модифицырованный кофф,который в принципе будет оставаться валидным
  • Who is online

    Users browsing this forum: No registered users and 20 guests