Загрузка библиотек

• Joaquin

  Posts 49

  Joined: Sat Aug 13, 2011 1:48 pm

  Mon Aug 15, 2011 5:24 am

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

  • Quote

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'

SII

Posts 214

Joined: Wed Dec 26, 2007 5:09 am

Mon Aug 15, 2011 1:26 pm

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

• Quote

art_zh Kernel Developer

Posts 1465

Joined: Fri Aug 14, 2009 1:46 am

Mon Aug 15, 2011 6:14 pm

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

• Quote

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

Code: Select all

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

[/size]