Забить /rd/1 под завязку (например логом board). Писать скомпилированный файл будет некуда -> Write failedНе подскажете как сэмулировать состояние write failed для какого-нибудь файла.
Вопрос(ы) по internals(кишкам) Колибри
Появились еще вопросы:
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 внутри колибри будет адски неудобен для разработки из под самой колибри.
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 внутри колибри будет адски неудобен для разработки из под самой колибри.
Any initialization a library needs, e.g. libimg. Or may be you want to precompute tables of magic numbers.ProMiNick wrote:1) lib_init нужна для загрузки импортов самого импортированного файла (и только?)?
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:Зачем ей передаются ссылки на функции работы с памятью?
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
5,6) - время показало ущербность и излишнюю сложность реализаций
Еще вопрос: может ли программа быть "не джентельменом" и модифицировать саму себя(т.е. модифицировать исполнимый файл, образ которого сейчас в памяти на исполнение)? это было бы еще удобнее чем ини файлы - антивирусов то нет)
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.ProMiNick wrote:Еще вопрос: может ли программа быть "не джентельменом" и модифицировать саму себя(т.е. модифицировать исполнимый файл, образ которого сейчас в памяти на исполнение)? это было бы еще удобнее чем ини файлы - антивирусов то нет)
Who is online
Users browsing this forum: No registered users and 0 guests