Длина командной строки и пути к файлу при запуске

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

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

    Code: Select all

    	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 килобайт ОЗУ, но интересно - такой вариант не рассматривался?
  • SoUrcerer wrote:Здорово, супер. А разве ядро не может выделить памяти столько, сколько нужно для содержимого командной строки, и затем выделить её, и передать указатель? Я понимаю, что в самом лучшем случае можно сэкономить 60 килобайт ОЗУ, но интересно - такой вариант не рассматривался?
    Ядро может выделить сколько есть длины строки в текущий момент (это я просто максимальное значение ограничил) с учетом наличия максимального количества памяти, а приложению нужно уже иметь максимально выделенный объем. Так что в самом худшем случае уже будет 64+64=128 Кб.

    Вопрос с очень длинными строкам (over 100500) по моему субъективному личному мнению должен решаться через именованную (расшаренную память) - это достаточно специфические случаи и держать ради этого максимальный объем еще и в запускаемом приложении немного неразумно.
    SoUrcerer wrote:Я понимаю, что в самом лучшем случае можно сэкономить 60 килобайт ОЗУ
    На самом деле можно сэкономить 64 Кб -256 байт, так как используется старый статично выделенный буфер на 256 байт и выделения памяти через менеджер памяти не происходит.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4

    Code: Select all

    temp_area:
       rb  64*1024 ; new max cmdline 64 Kb
    Не айс. Эта память будет выделяться всегда и полностью, что не очень хорошо. Я бы предложил считать длину командной строки и прибавлять к .mem_size. Соответственно .mem_size будет будет началом строки. Учитывая постраничное выделение памяти и в большинстве случаев короткую строку, дополнительного расхода памяти не будет совсем.
    Last edited by Serge on Sat Jul 20, 2013 5:09 pm, edited 1 time in total.
  • Serge
    1) Насколько я помню ты же заявлял, что менеджер памяти выделяет страницы не сразу, а лишь по факту первого обращения. Соответственно будет выделено столько, сколько записано.
    2) Лично в моих программах подобные области несут многоцелевое использование, так что не пропадет.
    3) Если у тебя есть "айс" варианты, то я не запрещаю их тебе реализовывать. :-)
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Mario_r4
    1. Это только для 68.12. Память под образ выделяется сразу.
    3.Предложение в обновлённом посте выше.
    Я так и сделаю, расширю "MENUET02" заголовок, или будет новый "KOLIBRI", совместимый с i386ABI.
  • Serge wrote:Я так и сделаю, расширю "MENUET02" заголовок, или будет новый "KOLIBRI", совместимый с i386ABI.
    Согласен. Я сам уже думал над таким подходом - сменой заголовка на "KOLIBRI", но уж больно там код укуренный - если совсем честно то ломало его осиливать, а кавалерийским наскоком не прокатило. :-)

    За одно можно сразу и для пути к самому запущенному файлу динамически сделать. Только ты потом обстоятельно опиши как использовать, а не как обычно сделал и даже документацию не меняешь.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Serge wrote:Я бы предложил считать длину командной строки и прибавлять к .mem_size. Соответственно .mem_size будет будет началом строки.
    Объясни, как это будет работать, например:

    Code: Select all

    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:
    

    Code: Select all

    ext_dest_cmdline:
       dd 0xffffffff ; тэг или флаг указывающий на наличие поддержки расширенной командной строки
       dd temp_area ; собственно сам указатель на область в 64 Кб
    Serge wrote:Не айс. Эта память будет выделяться всегда и полностью, что не очень хорошо.
    Согласен. Почему бы тогда просто не указать, какой размер имеет область под командную строку, например, в тэге(tag = -(param_size))?
    Last edited by 0CodErr on Sat Jul 20, 2013 7:59 pm, edited 1 time in total.
  • 0CodErr
    У тебя в коде метки memory нет и stack неизвестно где находится, не скомпилируется.
  • Serge, добавил выше метки memory и stack.
  • 0CodErr
    memory и mem_size из моего примера синонимы. Это количество памяти, выделяемой статически, при создании процесса. Ядру несложно увеличить это количество на длину командной строки. Память выделяется постранично, и в большинстве случаев количество страниц не увеличится.
    Кстати, модифицированное предложение.

    Code: Select all

    если params не равно 0 и длина командной строки не равна 0
        если длина командной строки меньше 256, копируем строку в буфер params
        иначе увеличиваем mem_size на длину командной строки + 1 байт ,
        копируем командную строку и завершающий 0,
        заменяем в заголовке params на mem_size,
        заменяем в заголовке значение mem_size на новое  
    
    Чтобы всё работало, приложения должны брать адрес командной строки из заголовка.
  • Главное для старых приложений оставить как есть, а под новый заголовок будем переписывать постепенно.
    Всем чмоки в этом проекте! Засуньте эти 11 лет себе в жопу!
  • Serge wrote:Кстати, модифицированное предложение.
    Предлагаю сделать похожим образом ещё и c path(путь к программе).

    Code: Select all

    если params не равно 0 и длина командной строки не равна 0
        если длина командной строки меньше 256, копируем строку в буфер params
    А если будет больше, то что делать с областью 256 байт? Если это будет уже при другом заголовке(MENUET02, например) то, может быть, лучше приложению самому не выделять вообще никогда память под параметры? Пусть ядро всегда записывает в params в заголовке адрес параметров.
  • 0CodErr
    256 байт будут теряться. И надо проверять код на совместимость. Так что всё это скорее имеет смысл для нового заголовка, а там может быть что угодно.
  • Who is online

    Users browsing this forum: No registered users and 3 guests