Posted: Fri May 12, 2006 3:41 pm
Я за COFF!!! Попробую загрузить объектный файл (да хотя бы из gif_lite.inc) на уровне приложения
Page 7 of 15
Posted: Fri May 12, 2006 4:15 pm
Ну тогда может лучше ELF.
Posted: Fri May 12, 2006 4:42 pm
Не обязательно останавливаться только на COFF, возможно ELF лучше хотя MS его не поддерживает.
Что касается связывания то точкой входа может быть первый адрес секции кода, а связывание делать примерно так как сейчас у ДЛЛ таблица с указателями на экспортируемые функции/данные у программы такая же с импортируемыми. Программа передает ДЛЛ адрес своей таблицы, та ее заполняет и дальше все вызовы идут косвено например call [myDLLfunc]. Еще один момент: DLL были задуманы для экономии памяти при совместном использовании сегментов кода разными программами. Пока что DLL больше похожа на статическую библиотеку, которая линкуется при загрузке почти как в UNIX
Что касается связывания то точкой входа может быть первый адрес секции кода, а связывание делать примерно так как сейчас у ДЛЛ таблица с указателями на экспортируемые функции/данные у программы такая же с импортируемыми. Программа передает ДЛЛ адрес своей таблицы, та ее заполняет и дальше все вызовы идут косвено например call [myDLLfunc]. Еще один момент: DLL были задуманы для экономии памяти при совместном использовании сегментов кода разными программами. Пока что DLL больше похожа на статическую библиотеку, которая линкуется при загрузке почти как в UNIX
Posted: Fri May 12, 2006 4:50 pm
По поводу точки входа: обсудил с теми кто бывает на ИРК,решили не нужное это(хотя реализовать это очень просто). Секций как таковых у меня пока нет.
Вызовы у меня и так идут косвенно по сути. Пока таблицы импорта не реализовал. Надо в ручную получать адрес функции.
А как экономить память так и не придумали. Надо чтобы во всех прогах длл грузилась по одному адресу,или делать позиционно-независимый код
Не совсем линкуется при загрузке. Линкуется после вызова loadlibrary. Надо пока самому выделять место под указатели на импортируемые функции
Вызовы у меня и так идут косвенно по сути. Пока таблицы импорта не реализовал. Надо в ручную получать адрес функции.
А как экономить память так и не придумали. Надо чтобы во всех прогах длл грузилась по одному адресу,или делать позиционно-независимый код
Не совсем линкуется при загрузке. Линкуется после вызова loadlibrary. Надо пока самому выделять место под указатели на импортируемые функции
Posted: Fri May 12, 2006 5:16 pm
Практически одно и тоже. Позднее связывание.Не совсем линкуется при загрузке. Линкуется после вызова loadlibrary. Надо пока самому выделять место под указатели на импортируемые функции
А точку входа делать все равно придется. Библиотека должна себя настраивать так что без LibMain или DllEntry или InitDll не обойтись.
Posted: Fri May 12, 2006 5:20 pm
Настройкой займётся как решили функция загрузки. Она сразу раставит релоки,проверит есть ли импортируемы дллки
Posted: Fri May 12, 2006 5:34 pm
Речь не о релоках. Библиотеке может понадобится настроить свои данные, создать динамические буферы мамяти и т.пНастройкой займётся как решили функция загрузки. Она сразу раставит релоки,проверит есть ли импортируемы дллки
Posted: Fri May 12, 2006 5:40 pm
Инициализировать можно и не так. Поддубный считает что функции инициализации так явно заданные не нужны.
Posted: Fri May 12, 2006 5:45 pm
А если DLL надо выделить 4Мб памаяти под буфер для своих нужд или 12 Мб в зависимости от системы. Или она использует разные версии функций одни MMX, другие SSE или SSE2 или 3dNow что делать? Вариантов может быть миллион особенно если библиотека больше нескольких десятков байт.
Posted: Fri May 12, 2006 5:56 pm
Можно выбрать свой формат и одновременно избежать проблем с компиляторами, если написать преобразователь объектников из COFF/MSCOFF/PE/ELF. Какие проблемы?
Релокациями занимается загрузчик, который, видимо, тесно переплетён с менеджером ДЛЛ и поэтому является с ним одним целым...
Библиотеки 3-его кольца (т.е. вне ядра), конечно, не плохо, но всё же этот подход очень ограничен.
Что касается инициализации при загрузке, то ИМХО лучше явно вызывать "конструктор", если он нужен. Хотя можно сделать, лишним может и не будет.
Релокациями занимается загрузчик, который, видимо, тесно переплетён с менеджером ДЛЛ и поэтому является с ним одним целым...
Библиотеки 3-его кольца (т.е. вне ядра), конечно, не плохо, но всё же этот подход очень ограничен.
Что касается инициализации при загрузке, то ИМХО лучше явно вызывать "конструктор", если он нужен. Хотя можно сделать, лишним может и не будет.
Posted: Fri May 12, 2006 5:56 pm
Я о таких деталях и не думал.
Думал каждой длл давать указатель на функции мп(alloc,free) а там сами разберутся.
И к томуже в каждой длл может быть своя секция неинициализированных данных.
Думал каждой длл давать указатель на функции мп(alloc,free) а там сами разберутся.
И к томуже в каждой длл может быть своя секция неинициализированных данных.
Posted: Fri May 12, 2006 5:57 pm
Victor
Я насчет
Библиотеки для меня пока темная тема. Я мало, что в них понимаю.
А вообще по поводу того, что ты выложил, я хочу сделать маленькое замечание (надеюсь без обид?).
Когда выкладываешь любой продукт, пусть даже недоделанный нужно всегда писать как минимум Readme.txt в котором нужно хоть вкратце написать:
1) Кто автор
2) Зачем эта вещь нужна
3) Как эту вещь использовать
Без этого надеяться на резкий отклик всех и вся неразумно.
У каждого человека мозги работают по своему, даже если ему тема знакома.
Я насчет
Я стараюсь помогать людям, но в основном там, где хоть чего-то соображаю.Как говорил Mario79,главное что заметили
Библиотеки для меня пока темная тема. Я мало, что в них понимаю.
А вообще по поводу того, что ты выложил, я хочу сделать маленькое замечание (надеюсь без обид?).
Когда выкладываешь любой продукт, пусть даже недоделанный нужно всегда писать как минимум Readme.txt в котором нужно хоть вкратце написать:
1) Кто автор
2) Зачем эта вещь нужна
3) Как эту вещь использовать
Без этого надеяться на резкий отклик всех и вся неразумно.
У каждого человека мозги работают по своему, даже если ему тема знакома.
Posted: Fri May 12, 2006 6:03 pm
Простой пример: библиотека архиватор использует CRC32. Таблицы можно использовать статические а можно их расчитать динамически но тогда понадобится функция Init(). Об этом речь. Лучше продумывать все на реальном рабочем примере а не на простешем "Hello world"
Конечно можно но зачем изобретать опять свой уникальный велосипед. Почему не приводить все тогда к ELF/COFF/OMF?Можно выбрать свой формат и одновременно избежать проблем с компиляторами, если написать преобразователь объектников из COFF/MSCOFF/PE/ELF. Какие проблемы?
Posted: Sat May 13, 2006 11:35 am
0.05 рубля 
>Конечно можно но зачем изобретать опять свой уникальный велосипед. Почему не приводить все тогда к ELF/COFF/OMF?
Идеология меоси как хобби операционки - сделать все своими руками. Эдакая лаборатория для экспериментов. ИМХО свой формат - это меось стиль
>Конечно можно но зачем изобретать опять свой уникальный велосипед. Почему не приводить все тогда к ELF/COFF/OMF?
Идеология меоси как хобби операционки - сделать все своими руками. Эдакая лаборатория для экспериментов. ИМХО свой формат - это меось стиль
Posted: Sat May 13, 2006 12:03 pm
Хочется,чтобы программы,написанные под другие операционные системы,работали и в Колибри.Чтобы можно было взять исходники видеоплеера(и других программ),написанного на C или C++,и скомпилировать их под Колибри.В этом случае при выборе операционной системы народ будет склоняться в пользу Колибри,а не Виндовс.Ведь там те-же программы будут работать быстреее и виснуть не будут.
Но это совсем не означает,что в Колибри не должна быть своя специфика.Можно сделать поддержку и виндовских DLL -ок и сделать свои.Свои можно(скорее даже нужно) писать на ассемблере.При этом DLL написанная на ассемблере, будет меньше своего C-шного аналога как минимум в разы и к тому-же значительно быстрее.
А свой формат нужно делать хотя бы для того,чтобы не все программы из Колибри можно было перенести на другие ОС.Чтобы Колибри стояла на компьютере хотябы из-за того,что в Колибри есть какя-то классная программа(игрушка например) неимеющая аналога на других платформах.
Но это совсем не означает,что в Колибри не должна быть своя специфика.Можно сделать поддержку и виндовских DLL -ок и сделать свои.Свои можно(скорее даже нужно) писать на ассемблере.При этом DLL написанная на ассемблере, будет меньше своего C-шного аналога как минимум в разы и к тому-же значительно быстрее.
А свой формат нужно делать хотя бы для того,чтобы не все программы из Колибри можно было перенести на другие ОС.Чтобы Колибри стояла на компьютере хотябы из-за того,что в Колибри есть какя-то классная программа(игрушка например) неимеющая аналога на других платформах.