Page 2 of 2

Re: Вопрос(ы) по internals(кишкам) Колибри

Posted: Fri Dec 07, 2018 10:12 am
by Ray
Не подскажете как сэмулировать состояние write failed для какого-нибудь файла.
Забить /rd/1 под завязку (например логом board). Писать скомпилированный файл будет некуда -> Write failed

Re: Вопрос(ы) по internals(кишкам) Колибри

Posted: Wed Dec 26, 2018 10:08 am
by ProMiNick
Появились еще вопросы:
1) lib_init нужна для загрузки импортов самого импортированного файла (и только?)? Зачем ей передаются ссылки на функции работы с памятью?
2) код для загрузки объектной библиотеки присутствует в каждой такой библиотеке - вместо того, чтобы единожды пробрасываться из исполняемого модуля (подобно тому как неизвестно зачем пробрасываются функции работы с памятью)
3) в исполняемом модуле не сохраняется дерево всех загруженных модулей так, чтоб LoadLibrary грузило бы в адресное пространство объектный модуль ТОЛЬКО ЕДИНОЖДЫ командой mcall SF_SYS_MISC,SSF_LOAD_DLL,library_path, а в остальных случаях просто возвращало уже готовый указатель на таблицу экспорта нужного модуля (или "mcall SF_SYS_MISC,SSF_LOAD_DLL" - сама "умная" и не грузит модуль дважды, а просто возвращает указатель).
4) нельзя ли сделать так чтоб некоторые объектные модули (хотя бы 1) пробрасывались в адресное пространство исполнимого файла по умолчанию (аналогично пробросу kernel32.dll & ntdll.dll они всегда присутствуют в загруженых модулях процесса Windows)? (это способ еще раз улучшить описываемое в 2) - чтоб в исполняемых модулях код загрузки библиотек не дублировался, да еще и не дублировался в самих исполнимых файлах).
5) реестр - централизованное хранилище может быть удобнее ini файлов (не заменой, а дополнением) (случай когда многим приложениям надо хранить общие настройки) - никто не говорит, что реализовывать его в формате текстовом, напротив можно в виде бинарной базы данных распределенной между многими файлами.
6) и интерфейсы(в добавление к реестру) - неплохо пробрасывать из объектных модулей не отдельные процедуры, а объекты (или интерфейсы).(и ХЛЛльщикам будет попроще, особенно если увидят "родные" интерфейсы с родными GUID и методами). для начала хватило бы 2х IUnknown и IClassFactory

Первые 3 - это вопросы. Остальное так, размышления.
и еще вопросы:
переменные среды - есть в kolibri?
есть ли возможность указать в fasm внутри колибри не во время компиляции путь до папки include? А если быть честным с собой, то - возможность указать сразу несколько путей разделенных точкой с запятой? или это только через ini файл?
т.к. без возможности указывать папку включения (сразу несколько папок) fasm внутри колибри будет адски неудобен для разработки из под самой колибри.

Re: Вопрос(ы) по internals(кишкам) Колибри

Posted: Thu Dec 27, 2018 5:29 am
by dunkaist
ProMiNick wrote:1) lib_init нужна для загрузки импортов самого импортированного файла (и только?)?
Any initialization a library needs, e.g. libimg. Or may be you want to precompute tables of magic numbers.
ProMiNick wrote:Зачем ей передаются ссылки на функции работы с памятью?
It is often easier to develop and debug a library on, say, Linux. Not using system calls helps here a lot. I don't think this is because of possible userspace allocators.
ProMiNick wrote:2) код для загрузки объектной библиотеки присутствует в каждой такой библиотеке - вместо того, чтобы единожды пробрасываться из исполняемого модуля (подобно тому как неизвестно зачем пробрасываются функции работы с памятью)

Code: Select all

;;===========================================================================;;
lib_init: ;//////////////////////////////////////////////////////////////////;;
;;---------------------------------------------------------------------------;;
;? Library entry point (called after library load)                           ;;
;;---------------------------------------------------------------------------;;
;> eax = pointer to memory allocation routine                                ;;
;> ebx = pointer to memory freeing routine                                   ;;
;> ecx = pointer to memory reallocation routine                              ;;
;> edx = pointer to library loading routine                                  ;;
;;---------------------------------------------------------------------------;;
;< eax = 1 (fail) / 0 (ok) (library initialization result)                   ;;
;;===========================================================================;;
        mov     [mem.alloc], eax
        mov     [mem.free], ebx
        mov     [mem.realloc], ecx
        mov     [dll.load], edx
        mov     [DNSrequestID], 1
        xor     eax, eax
        ret
3,4) http://board.kolibrios.org/viewtopic.php?f=1&t=1839

Re: Вопрос(ы) по internals(кишкам) Колибри

Posted: Thu Dec 27, 2018 8:33 am
by Siemargl
5,6) - время показало ущербность и излишнюю сложность реализаций

Re: Вопрос(ы) по internals(кишкам) Колибри

Posted: Thu Dec 27, 2018 2:35 pm
by ProMiNick
Еще вопрос: может ли программа быть "не джентельменом" и модифицировать саму себя(т.е. модифицировать исполнимый файл, образ которого сейчас в памяти на исполнение)? это было бы еще удобнее чем ини файлы - антивирусов то нет)

Re: Вопрос(ы) по internals(кишкам) Колибри

Posted: Fri Dec 28, 2018 12:06 am
by dunkaist
ProMiNick wrote:Еще вопрос: может ли программа быть "не джентельменом" и модифицировать саму себя(т.е. модифицировать исполнимый файл, образ которого сейчас в памяти на исполнение)? это было бы еще удобнее чем ини файлы - антивирусов то нет)
I implemented high score table in my snake game this way. However kpack'ing breaks this logic and therefore I switched to a separate file.