Board.KolibriOS.org

Сейчас для того, чтобы загрузить одну/несколько библиотек, различные приложения используют либо сущеcтвующие макросы (например, "load_lib.mac"), либо каждый раз пишут свой велосипед в виде кода, который подгружает нужные DLL-ки. А может лучше вынести код_загрузки_нужных_библиотек_по_таблице_импорта в ядро, т.е. в сифункцию? Ведь очевидно будут плюсы:
• программы станут легче на 5-10%, их код станет более компактным и удобочитаемым
• ядро сможет выводить стандартное сообщение об отстуствующих/устаревших библиотека в случае ошибки при загрузке (сейчас же,в такой ситуации, многие приложения тупо падают без всяких объяснений, и это мягко говоря "озадачивает" пользователя
• со временем можно будет обновить формат MENUETxx-экзешников, добавив в заголовок поле с указателем на таблицу импорта - таким образом ядро при загрузке будет вызывать уже существующую процедуру

Честно говоря, несмотря на то, что я за то, чтобы максимально высвободить ядро от функций, которые оно делать не должно, но эта функция представляется мне как раз той, что действительно необходима в ядре.

Впрочем, я и сейчас не вижу особых проблем.
К примеру, вот пару дней назад я переписал вызов fontslib с использования loadlib.mac на dll.inc, синтаксис работы с библиотеками в котором мне нравится больше. Сделал быстро и код вполне читабелен:

START:
   mcall   68,11
   stdcall dll.Load,@IMPORT
   or   eax,eax
   jnz   exit
   ; Инциализация библиотеки fontslib
   invoke fonts.init   ; инициализация списка шрифтов 
   invoke fonts.get_font

...

@IMPORT:
library \
   fontslib,'fonts_lib.obj'

import fontslib, \
   fonts.init            ,'initialization_font',\
   fonts.get_font         ,'get_font',\
   fonts.free_fulder_info   ,'free_fulder_info',\
   fonts.free_font         ,'free_font',\
   fonts.draw_string      ,'font_draw_on_string',\
   fonts.show_all         ,'show_all_glif',\
   fonts.version         ,'version_fn'

Готово, все нужные функции доступны через invoke.

Я тоже за "облегчение" ядра посредством переноса всех левыхъ функций В библиотеки и именно поэтому предложил эту идею.
Также использование макросов/велосипедного кода имеет минус для небольших, крошечных программ, имхо. Ибо код загружающий библиотеку в них может занимать места больше, чем основной код программы. С использованием же системного вызова он будет занимать 8-15 байт.

Загрузчику, как и "тяжёлым" драйверам (вроде файловых систем) в ядре делать нечего: они его прилично раздувают и усложняют, а выигрыша в плане скорости такое решение практически не даёт (в связи с медленной работой "по определению" этих компонентов: оно настолько превосходит время переключения контекста, что им можно смело пренебречь). Целесообразнее их делать в виде задач режима пользователя, общающихся с ядром через стандартизированный интерфейс. Помимо всего прочего, это прилично облегчит написание и отладку таких компонентов, а также обеспечит лёгкость их расширения. Наконец, поведение ядра, и, в частности, время его работы станет предсказуемее (время работы загрузчика или какого-нибудь тяжёлого драйвера предсказать вообще невозможно, поскольку оно зависит от внешних факторов, например, расположения файлов на диске). В случае с загрузчиком его вынос из ядра позволяет легко обеспечить загрузку и COFF, и ELF, и ещё каких-нибудь форматов, какие кому-то понадобятся, без каких-либо изменений в ядре. Другое дело, что надо проектировать, а потом реализовывать этот самый стандартный интерфейс, а также функции управления памятью (загрузчик-то должен иметь доступ к адресному пространству чужой задачи), да и вообще сначала думать, а потом писать...

Ну ничто не мешает сделать такую функцию для загрузки только COFF-библиотек (как стандартных и нативных для Колибри), а поддержку других исполняемых/линкуемых форматов переложить на загрузчики для user mode.

Выносить код загрузки библиотек из приложений, разумеется, нужно, но не в ядро, а в системную user-mode библиотеку, которая будет грузиться автоматически, получать управление до основного приложения и всё настраивать. Например, это позволяет без проблем вызывать функции инициализации в библиотеках - которые, естественно, должны выполняться в user-mode - и существенно разгружает ядро от деталей, которые там не нужны.

Длинный флейм по вопросам формата и загрузки динамических библиотек был на форуме здесь и здесь. В конечном счёте вроде активные на тот момент ядерщики согласились на формат PE с урезанным заголовком, но, как это часто бывает с флеймами, всё загнулось.

_________________
Сделаем мир лучше!

Если вытащить загрузку программ/библиотек из нулевого кольца, то можно будет вовсе отказаться от идеи "Каждой ОС свои форматы экзешников и либ". Программист будет выбирать тот формат, который ему по душе и/или с которым он лучше_знаком/привык_работать.

Точнее, с которым умеет работать его любимый компилятор.

Загрузка из user-mode создаёт некоторые проблемы с расшареными библиотеками.

Joaquin: много форматов, тоже не очень хорошо.

Собственно, нужно нормальное управление памятью, и в частности, её совместным использованием несколькими задачами. Если такового нет, то реализовать загрузчик в режиме пользователя не получится (ну, не считая включения его кода в каждую задачу -- пускай и в виде системной библиотеки, автоматически загружаемой ядром при запуске задачи).

Это просто общая шиза какая-то: выносить из ядра всё, что работает...

_________________
Евангелие от Иоанна: стих 1

Code:

; В начале было Слово:
B32:        mov     ax, os_stack       ; Selector for os

art_zh, в данном случае проблема в том, что сейчас загрузка библиотек не работает. По крайней мере, нормально. По причинам, которые изложил Joaquin в первом же посте этой темы.
SII, я, конечно, понимаю, что вам лишь бы поругать отсутствие проектирования и документации на внутреннее устройство ядра где-либо, кроме мозгов разработчиков, и что вам безразлично, что на самом деле уже есть, но для вновь прибывших я считаю своим долгом сообщить о существовании расшаренной памяти на уровне API - функции 68.22 и 68.23. К которым нет принципиальных проблем прикрутить примочки типа copy-on-write. Если, конечно, не считать того, что делать это некому, но указанная проблема не является специфичной для обсуждаемой темы.

_________________
Сделаем мир лучше!

Кстати о "выносить из ядра всё, что работает"... Это только мне одному кажется, что LZMA-распакеру в ядре делать нечего?

Ядро же запакованное, как оно само себя распаковывать будет?