GerdtR
Почему?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Spoiler:

! E:\Kolibri\zip\6666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666.zip: Невозможно создать Kolibri\zip\6666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666666\55555555555555555555555555555555555555555555555555555\tzip-viewer\TZip_Viewer\PROJECT1.dpr
Общая длина пути и имени файла не должна превышать 260 символов

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

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

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

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

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