Ну тогда может лучше ELF.

Не обязательно останавливаться только на COFF, возможно ELF лучше хотя MS его не поддерживает.
Что касается связывания то точкой входа может быть первый адрес секции кода, а связывание делать примерно так как сейчас у ДЛЛ таблица с указателями на экспортируемые функции/данные у программы такая же с импортируемыми. Программа передает ДЛЛ адрес своей таблицы, та ее заполняет и дальше все вызовы идут косвено например call [myDLLfunc]. Еще один момент: DLL были задуманы для экономии памяти при совместном использовании сегментов кода разными программами. Пока что DLL больше похожа на статическую библиотеку, которая линкуется при загрузке почти как в UNIX

По поводу точки входа: обсудил с теми кто бывает на ИРК,решили не нужное это(хотя реализовать это очень просто). Секций как таковых у меня пока нет.
Вызовы у меня и так идут косвенно по сути. Пока таблицы импорта не реализовал. Надо в ручную получать адрес функции.
А как экономить память так и не придумали. Надо чтобы во всех прогах длл грузилась по одному адресу,или делать позиционно-независимый код
Не совсем линкуется при загрузке. Линкуется после вызова loadlibrary. Надо пока самому выделять место под указатели на импортируемые функции

Не совсем линкуется при загрузке. Линкуется после вызова loadlibrary. Надо пока самому выделять место под указатели на импортируемые функции

Практически одно и тоже. Позднее связывание.
А точку входа делать все равно придется. Библиотека должна себя настраивать так что без LibMain или DllEntry или InitDll не обойтись.

Настройкой займётся как решили функция загрузки. Она сразу раставит релоки,проверит есть ли импортируемы дллки

Настройкой займётся как решили функция загрузки. Она сразу раставит релоки,проверит есть ли импортируемы дллки

Речь не о релоках. Библиотеке может понадобится настроить свои данные, создать динамические буферы мамяти и т.п

Инициализировать можно и не так. Поддубный считает что функции инициализации так явно заданные не нужны.

А если DLL надо выделить 4Мб памаяти под буфер для своих нужд или 12 Мб в зависимости от системы. Или она использует разные версии функций одни MMX, другие SSE или SSE2 или 3dNow что делать? Вариантов может быть миллион особенно если библиотека больше нескольких десятков байт.

Можно выбрать свой формат и одновременно избежать проблем с компиляторами, если написать преобразователь объектников из COFF/MSCOFF/PE/ELF. Какие проблемы?

Релокациями занимается загрузчик, который, видимо, тесно переплетён с менеджером ДЛЛ и поэтому является с ним одним целым...

Библиотеки 3-его кольца (т.е. вне ядра), конечно, не плохо, но всё же этот подход очень ограничен.

Что касается инициализации при загрузке, то ИМХО лучше явно вызывать "конструктор", если он нужен. Хотя можно сделать, лишним может и не будет.

Я о таких деталях и не думал.
Думал каждой длл давать указатель на функции мп(alloc,free) а там сами разберутся.
И к томуже в каждой длл может быть своя секция неинициализированных данных.

Victor
Я насчет

Как говорил Mario79,главное что заметили

Я стараюсь помогать людям, но в основном там, где хоть чего-то соображаю.
Библиотеки для меня пока темная тема. Я мало, что в них понимаю.
А вообще по поводу того, что ты выложил, я хочу сделать маленькое замечание (надеюсь без обид?).
Когда выкладываешь любой продукт, пусть даже недоделанный нужно всегда писать как минимум Readme.txt в котором нужно хоть вкратце написать:
1) Кто автор
2) Зачем эта вещь нужна
3) Как эту вещь использовать
Без этого надеяться на резкий отклик всех и вся неразумно.
У каждого человека мозги работают по своему, даже если ему тема знакома.

Простой пример: библиотека архиватор использует CRC32. Таблицы можно использовать статические а можно их расчитать динамически но тогда понадобится функция Init(). Об этом речь. Лучше продумывать все на реальном рабочем примере а не на простешем "Hello world"

Можно выбрать свой формат и одновременно избежать проблем с компиляторами, если написать преобразователь объектников из COFF/MSCOFF/PE/ELF. Какие проблемы?

Конечно можно но зачем изобретать опять свой уникальный велосипед. Почему не приводить все тогда к ELF/COFF/OMF?

0.05 рубля

>Конечно можно но зачем изобретать опять свой уникальный велосипед. Почему не приводить все тогда к ELF/COFF/OMF?

Идеология меоси как хобби операционки - сделать все своими руками. Эдакая лаборатория для экспериментов. ИМХО свой формат - это меось стиль

Хочется,чтобы программы,написанные под другие операционные системы,работали и в Колибри.Чтобы можно было взять исходники видеоплеера(и других программ),написанного на C или C++,и скомпилировать их под Колибри.В этом случае при выборе операционной системы народ будет склоняться в пользу Колибри,а не Виндовс.Ведь там те-же программы будут работать быстреее и виснуть не будут.

Но это совсем не означает,что в Колибри не должна быть своя специфика.Можно сделать поддержку и виндовских DLL -ок и сделать свои.Свои можно(скорее даже нужно) писать на ассемблере.При этом DLL написанная на ассемблере, будет меньше своего C-шного аналога как минимум в разы и к тому-же значительно быстрее.
А свой формат нужно делать хотя бы для того,чтобы не все программы из Колибри можно было перенести на другие ОС.Чтобы Колибри стояла на компьютере хотябы из-за того,что в Колибри есть какя-то классная программа(игрушка например) неимеющая аналога на других платформах.