Board.KolibriOS.org

Тема создана не столько с целью обсуждения, сколько с целью не забыть про необходимость изменений.

Поскольку статическое увеличение размера для этих двух строк не приемлемо по множеству причин, то необходимо динамическое выделение. Так что сделаю цитату своего же высказывания, чтобы не искать. Человек (в моем лице) склонен забывать некоторые свои идеи к сожалению.

Будет время - займусь реализацией, если никто раньше не сделает.

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

SVN r.3828 реализована поддержка расширенной командной строки. Поскольку должны быть разумные пределы, то я остановился на 64 Кб максимального размера. Этого более чем достаточно, насколько я видел существующих разделов с большими глубинами вложения директорий и файлов.
Для совместимости все старые программы оставлены в прежнем режиме - 256 символов, включая завершающий 0.

Для поддержки расширенной командной строки программ должна выглядеть приблизительно так:

   use32
   org 0x0
   db 'MENUET01'   ; 8 byte id
   dd 0x01      ; header version
   dd START   ; start of code
   dd IM_END   ; size of image
   dd I_END   ; memory for app
   dd stacktop   ; esp
   dd ext_dest_cmdline   ; I_Param
   dd path      ; APPLICATION PACH

...

ext_dest_cmdline:
   dd 0xffffffff ; тэг или флаг указывающий на наличие поддержки расширенной командной строки
   dd temp_area ; собственно сам указатель на область в 64 Кб

...

temp_area:
   rb  64*1024 ; new max cmdline 64 Kb

Поскольку ядерный менеджер памяти перед выделением памяти всегда очищает ее, то все работает как часы - если когда-нибудь менеджер памяти перестанет очищать память, то есть большая вероятность возникновения проблем. Будем надеяться, что таких "шуток" с менеджером памяти в будущем не будет.

В данный момент лишь программа zSea (SVN r.3829) переделана под расширенную командую строку.

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

Здорово, супер. А разве ядро не может выделить памяти столько, сколько нужно для содержимого командной строки, и затем выделить её, и передать указатель? Я понимаю, что в самом лучшем случае можно сэкономить 60 килобайт ОЗУ, но интересно - такой вариант не рассматривался?

Ядро может выделить сколько есть длины строки в текущий момент (это я просто максимальное значение ограничил) с учетом наличия максимального количества памяти, а приложению нужно уже иметь максимально выделенный объем. Так что в самом худшем случае уже будет 64+64=128 Кб.

Вопрос с очень длинными строкам (over 100500) по моему субъективному личному мнению должен решаться через именованную (расшаренную память) - это достаточно специфические случаи и держать ради этого максимальный объем еще и в запускаемом приложении немного неразумно.


На самом деле можно сэкономить 64 Кб -256 байт, так как используется старый статично выделенный буфер на 256 байт и выделения памяти через менеджер памяти не происходит.

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

Mario_r4

temp_area:
   rb  64*1024 ; new max cmdline 64 Kb

Не айс. Эта память будет выделяться всегда и полностью, что не очень хорошо. Я бы предложил считать длину командной строки и прибавлять к .mem_size. Соответственно .mem_size будет будет началом строки. Учитывая постраничное выделение памяти и в большинстве случаев короткую строку, дополнительного расхода памяти не будет совсем.

Serge
1) Насколько я помню ты же заявлял, что менеджер памяти выделяет страницы не сразу, а лишь по факту первого обращения. Соответственно будет выделено столько, сколько записано.
2) Лично в моих программах подобные области несут многоцелевое использование, так что не пропадет.
3) Если у тебя есть "айс" варианты, то я не запрещаю их тебе реализовывать.

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

Mario_r4
1. Это только для 68.12. Память под образ выделяется сразу.
3.Предложение в обновлённом посте выше.
Я так и сделаю, расширю "MENUET02" заголовок, или будет новый "KOLIBRI", совместимый с i386ABI.

Согласен. Я сам уже думал над таким подходом - сменой заголовка на "KOLIBRI", но уж больно там код укуренный - если совсем честно то ломало его осиливать, а кавалерийским наскоком не прокатило.

За одно можно сразу и для пути к самому запущенному файлу динамически сделать. Только ты потом обстоятельно опиши как использовать, а не как обычно сделал и даже документацию не меняешь.

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

Объясни, как это будет работать, например:

db 'MENUET01'
dd 1
dd start
dd end   
dd memory
dd stack 
dd params
dd path  
; code & data
start:
; code & data 
params: resb PARAM_SIZE
; code & data
end:

; UPD:
resb 256
stack:
memory:

ext_dest_cmdline:
   dd 0xffffffff ; тэг или флаг указывающий на наличие поддержки расширенной командной строки
   dd temp_area ; собственно сам указатель на область в 64 Кб

Согласен. Почему бы тогда просто не указать, какой размер имеет область под командную строку, например, в тэге(tag = -(param_size))?

0CodErr
У тебя в коде метки memory нет и stack неизвестно где находится, не скомпилируется.

Serge, добавил выше метки memory и stack.

0CodErr
memory и mem_size из моего примера синонимы. Это количество памяти, выделяемой статически, при создании процесса. Ядру несложно увеличить это количество на длину командной строки. Память выделяется постранично, и в большинстве случаев количество страниц не увеличится.
Кстати, модифицированное предложение.

если params не равно 0 и длина командной строки не равна 0
    если длина командной строки меньше 256, копируем строку в буфер params
    иначе увеличиваем mem_size на длину командной строки + 1 байт ,
    копируем командную строку и завершающий 0,
    заменяем в заголовке params на mem_size,
    заменяем в заголовке значение mem_size на новое  

Чтобы всё работало, приложения должны брать адрес командной строки из заголовка.

Главное для старых приложений оставить как есть, а под новый заголовок будем переписывать постепенно.

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

Предлагаю сделать похожим образом ещё и c path(путь к программе).

если params не равно 0 и длина командной строки не равна 0
    если длина командной строки меньше 256, копируем строку в буфер params

А если будет больше, то что делать с областью 256 байт? Если это будет уже при другом заголовке(MENUET02, например) то, может быть, лучше приложению самому не выделять вообще никогда память под параметры? Пусть ядро всегда записывает в params в заголовке адрес параметров.

0CodErr
256 байт будут теряться. И надо проверять код на совместимость. Так что всё это скорее имеет смысл для нового заголовка, а там может быть что угодно.