Зарезервированные слова в SysFn09 (информация о потоке )

Internal structure and you change requests/suggestions
  • Могу точно ответит на последний вопрос - наличие зарезервированного места хорошо по умолчанию, есть куда расширять и не надо ломать мозг как добавить новое поле - добавляешь и все.

    Насчет зарезервированных могу предложить - лучше не трогать. Неизвестно когда и кем было зарезервировано, но раз написано значит нужно. Есть другие поля в старшей части и можно писать в них. Свободного места полно.
  • Спасибо, Mario.

    Но я не совсем удовлетворён ответом насчёт более чем десятикратного запаса:понятно, что зарезервированное место - это необходимо, но почему, например, не 256 байт (тройной запас)? Вот если есть далеко идущий стратегический план, который потребует около 400 - 500 байт, тогда всё становится понятно ...
  • Кто-то подумал и решил, что 1Кб в самый раз. Это очень в духе Колибри, посмотри memmap.inc .
  • Serge
    При чем тут "дух Колибри"? Это унаследовано еще с Menuet.
  • Mario

    В этом плане не вижу никакой разницы. Там один байт сэкономили, тут с запасом зарезервировали.
  • Serge
    Я честное слово не понял что ты подразумевал - можешь развернуто изложить?
  • Mario wrote:Serge
    Я честное слово не понял что ты подразумевал - можешь развернуто изложить?
    Должно быть, тот грустный факт, что в статической области ядра чрезвычайно плотные структуры данных перемешаны с пустыми дырами (в десятки килобайт) и совершенно неуместными там таблицами и резервированными полями.

    имхо, если упорядочить системные переменные в const.inc и вынести громоздкие (иногда просто ненужные) структуры из статической зоны в Кучу, тогда вполне можно было бы сжать ядро до 500-700 килобайт и позиционировать Колибри как единственную в своем роде DRAM-независимую ОС.
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • art_zh wrote: имхо, если упорядочить системные переменные в const.inc и вынести громоздкие (иногда просто ненужные) структуры из статической зоны в Кучу, тогда вполне можно было бы сжать ядро до 500-700 килобайт и позиционировать Колибри как единственную в своем роде DRAM-независимую ОС.
    Насколько я понимаю такая работа велась, потому что некоторые структуры были описаны в виде логических структур, без непосредственного указания смещений относительно общей и глобальной базы, но ее так и не довели до логического финала.
    Насчет впихнуть в 1 Мб и менее с сохранением всей функциональности - я в это несколько не верю. Либо такая система будет работать ощутимо медленней.
  • ИМХО, 1024 килобайт вполне нормальный размер для буфера. Во-первых, в той же долбанной Windows, например, есть такая структура - PEB (Process Environment Block) размером ~500 байт. Во-вторых, функция 9 возвращает пока очень мало сведений о процессе - нельзя узнать полное имя исполняемого файла, командную строку, PID/TID родителя, информацию о используемых библиотеках, об IPC, открытых шаред-мемори блоков, открытых TCP/UDP портах, дочерних потоках и т.д. и т.п. :) .
    Если же жажда экономии всё-таки вас не покидает, можно передавать функции размер буфера, чтобы она не затирала другие данные в программе. Но в таком случае придётся помимо изменения самой сисфункции, править ещё и программы, её использующие (а это @panel, cpu, eolite, icon, shell и многие другие).
    ушёл...
  • Nasarus wrote:...можно передавать функции размер буфера, чтобы она не затирала другие данные в программе. Но в таком случае придётся помимо изменения самой сисфункции, править ещё и программы, её использующие (а это @panel, cpu, eolite, icon, shell и многие другие).
    Не обязательно - ты можешь предположить (например) первые 70 байт статическими, а после них (например в 76-80 байтах) поместить фактический размер переменного "хвоста" и какую-нибудь сигнатуру во избежание возможных заморочек (вариант: изменить зарезервированные байты по сабжу).
    Евангелие от Иоанна: стих 1

    Code: Select all

    ; В начале было Слово:
    B32:        mov     ax, os_stack       ; Selector for os
    [/size]
  • art_zh wrote: Не обязательно - ты можешь предположить (например) первые 70 байт статическими, а после них (например в 76-80 байтах) поместить фактический размер переменного "хвоста" и какую-нибудь сигнатуру во избежание возможных заморочек (вариант: изменить зарезервированные байты по сабжу).
    Не совсем понял, как таким образом можно избежать правок существующих программ.. :?:
    ушёл...
  • Тех которые резервируют менее 1 Кб не получится не править. Впрочем большинство программ используют выделенный буфер в 1 Кб - ибо большинство программистов все-же читают документацию, так как научены горьки опытом.
  • Mario

    art_zh замечательно ответил за меня. Я знаю что это тянется от Менуэт, но сваливать всё только на "темное царское прошлое" неправильно. Было достаточно времени на наведение порядка в данных ядра.

    P.S. Зачем 18.11 буфер в 64 Кб ? Это Вилле придумал?
  • Serge wrote:Было достаточно времени на наведение порядка в данных ядра.
    Я бы ответил встречным вопросом - "так чего же сам не навел порядок?", но будет это по аналогии "драк - сам дурак". Надо учитывать что каждый занимается тем чем умеет и главное тем что ему самому нравиться - "Just for fun". Тыкать пальцем во всех и каждого бессмысленно.
    Serge wrote: P.S. Зачем 18.11 буфер в 64 Кб ? Это Вилле придумал?
    Вообще-то ты скромно умалчиваешь сколько лет назад это было (мы ведь не рождаемся многомудрыми?), а также не менее скромно что я уже два года как минимум ядром не занимаюсь. Я конечно понимаю чужие недоработки видней - со стороны оно всегда видней. :lol:

    И никого не трогает, что когда это делалось менеджер памяти был еще совсем "не торт", он конечно и сейчас не особо "торт" - скорее пирожок или эклер. :mrgreen:

    Но может не будем сейчас заниматься выискиванием насекомых в головах и мозгах друг-друга?

    Я стараюсь придерживаться одного принципа: Можешь сделать лучше другого - делай, а не сокрушайся как все плохо. Последнее контрпродуктивный подход.
  • Who is online

    Users browsing this forum: No registered users and 5 guests