Board.KolibriOS.org

Ясно, облом в общем)

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!

GerdtR
Почему?

Ну т.е. PE библиотеку вот так сразу с помощью 68.19 не загрузить( Придётся драйвер писать. Ну или может и в юзер-моде большая часть работать будет, но писать придётся.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!

в начале программы инициализирую кучу:

    mov     eax,68
    mov     ebx,11
    int     0x40

потом пытаюсь выделять память под строки:

new_string:
    mov     eax,68
    mov     ebx,12
    mov     ecx,256
    int     0x40
    ret

собственно как и ожидал, вместо 256 байт выделяется 4096 (wiki: Функция выделяет целое число страниц (4 Кб)). И так за каждый вызов. То есть я, планируя выделить память под 4 строки длинной 256 байт (итого 1 кб), кушаю 16 кб памяти!

А теперь внимание вопрос: как сделать так, чтобы выделялось именно 256 байт (что-то типа менеджера реализовывать надо или есть более простой подход?).

В ядре такой функциональности для приложений нет.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

К кому можно обратиться для реализации подобного функционала? С реализацией: new_string, free_string, за вознаграждение до 20 $. (автор кода должен быть готов что код должен быть под BSD лицензией.)

Можно без проблем найти в сети различные менеджеры памяти с открытыми исходниками же.

ничего более менее толкового я не нашёл, причиной этому скорее всего не понимаемость того) как оно работает). Попробую пока сам написать. Пока не понимаю как производить дефрагментацию и не терять адреса на данные при удалении строки. Лан прорвёмся поди...

Akyltist, я для одного своего проекта соорудил две функции. Одна выделяет любой кусок памяти, а вторая убирает. Там принцип такой: Выделяется блок(его размер кратен 4096б и зависит от запрашиваемого размера). Дальше в нём в его начале отводиться часть для нужного куска памяти, а в конце создаётся таблица растущая к меньшим адресам, в которой записывается первый и последний адрес выделенных кусков. Если текущего блока уже мало, то создаётся новый, а в нём аналогичная таблица. Ну после создания/удаления кусков появляются свободные окна, но всё равно потери меньше получаются.

_________________
Чем больше сыра, тем больше в нём дыр. Чем больше дыр, тем меньше в нём собственно сыра. Значит, чем больше сыра, тем меньше сыра!

Тоже, когда то во времена экспериментального написания текстового мультиоконного событийного для DOS текстового редактора
решал подобную задачу. Сейчас всех подробностей не помню (нужно смотреть исходники проги), но использовал
списковые линки в структуре выделенного куска памяти. Дырки тоже вроде оставались, но редактор на слиянии, разделении строк
справлялся приемлемо. С утечкой памяти, вроде, не доконца тогда справился. Но полученный опыт был интересным и неоднозначным
при отладке иерархии элементов дизайна редактора. Код писал в рамках одной из Форт систем для DOS.

P.S. Есть некоторая вероятность что мне ещё захочется "покопаться" с данной разработкой.

Akyltist
А стоит ли овчинка выделки? Есть вероятность, что использование менеджера памяти даст заметное замедление скорости работы кода, да и в конечном счете внезапно окажется, что накладные расходы нивелируют экономию памяти. Может просто сразу выделять 4К вместо 256 байт? Меня терзают смутные сомнения что величина в 256 байт как-то связана с некоторыми системными ограничениями в ядре, которые не факт что будут постоянными величинами в будущем. Скажем то же значение для хранения путей к файлам сильно желательно делать с запасом - 4К как раз хороший-годный запас.

_________________
Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!

С обысными строками так и есть, по 4кб, но речь идет о неком аналоге ShortString (длинна 256 байт), это даст более приемлемые расходы памяти. Как пример, описание пути к файлу в тех же zip архивах, согласно сорцам 7z (array [0..255] of char) что конечно странно, учитывая что размер считывается в word а не в byte. Вот что например выдает винрар при попытке распаковать подобный архив, с длинной для путей больше 256 байт.

По поводу, стоит ли овчинка выделки? Не знаю, для кусков произвольной длины да, возможно накладные расходы все перекроют, но для выделения блоками по 256, думаю нет, как ни как кратное степени 2ки)

FreshLib johnfound-а смотрел?

Если убрать в kernel.asm строчку sysfn_terminate2: то выходит вот такое сообщение:

если убрать
dd sysfn_terminate2
по выше, под меткой sys_system_table:
то сообщение больше не выходит. Подскажите пожалуйста какая между ними взаимосвязь?
(номера строчек в сообщении от кода 0.7.7.0)

Сам спросил, сам ответил?