Board.KolibriOS.org

Mario

Это я к тому, что списывать всё на Вилле и Менует уже нельзя. Если не исправили, значит устраивает.
Когда я активно занимался ядром то наводил порядок в данных, сколько мог. Ты и сам это знаешь. Но работа эта нудная и неблагодарная, заниматься ей сейчас я не могу, а других желающих не видно.

Serge wrote:Если не исправили, значит устраивает.

Вот! Зерно истины!

Serge wrote:Когда я активно занимался ядром то наводил порядок в данных, сколько мог. Ты и сам это знаешь. Но работа эта нудная и неблагодарная, заниматься ей сейчас я не могу, а других желающих не видно.

Да, я знаю потому не стал тыкать пальцем, о чем в предыдущем посте и сказал. Дело не в желающих, а в назревшей необходимости. У кого во что упирается и ограничивается, тот тем и занимается. Наведение порядка исключительно ради наведения порядка - на это мало кто решается. Да, собственно ты сам обозначил "Если не исправили, значит устраивает." - добавлю значит не мешает жить и работать. Когда-нибудь, кто-нибудь - допилит, если будет необходимость.

Nasarus wrote:Не совсем понял, как таким образом можно избежать правок существующих программ..

У 9-й функции очень кривой вызов, даже подфункцию не воткнешь.
Но расширенный системный сервис все-таки можно реализовать, если использовать для этого саму структуру.
В новых программах при 9-м вызове можно где-нибудь записать какую-нибудь характерную сигнатуру (например db 'Nasarus',0 )
- тогда ядро будет знать, что нужно будет заполнять структуру после 75-го байта, и еще места хватит для размера "хвоста", номера подфункции и чего еще душа пожелает.

art_zh, теперь понял, спасибо что объяснил

Лучше новый вызов сделать, так надёжнее. И для него разработать новый формат структуры.

Serge, +5. Нужно заранее продумать структуру, чтобы информация об окне шла в одном диапазоне, PID/TID собсвтенный/родителя/дочерних потоков в другом диапазоне, остальная информация тоже должна быть разложена "по полочкам". Во-вторых, надо вместо строк (имя файла, например) ложить в буфер указатели на них.

У меня возникла аналогичная мысль. Приведу её в относительно развёрнутом виде.

A. Проект плана действий

(1) До следующей стабильной версии создаём новую функцию, позволяющую получить всю информацию, которую пока можно получить только посредством SysFn09. Эта функция уже
- должна быть в духе KolibriOS,
- не содержать недостатков SysFn09.
(см. ниже в Б.)
(2) В следующей стабильной версии KolibriOS:
- SysFn09 объявляем как Deprecated;
- в качестве приоритетного TODO устанавливаем замену вызовов SysFn09 на вызовы новой функции во всех приложениях.
- в качестве среднесрочного TODO устанавливается размещение всех структур ядра KolibriOS так, чтобы отдельные записи не пересекали страничных барьеров несмежных страниц в физической памяти (или что-то в таком духе: см п. (3) )
(3) Когда предыдущий этап будет полностью завершён (прогнозирую, что это будет реально через 2 - 3 года)
- SysFn09 становится недоступной для обычных приложений (которые, естественно, не имеют никакого доступа к адресному пространству ядра): возвращает код ошибки;
- для привилегированных приложений, которые имеют доступ к адресному пространству ядра в режиме "только для чтения", SysFn09 (а): возвращала (в eax) код ошибки/успеха + (в ebx) адрес соответствующей структуры ядра (на всякий случай дополню - в адресном пространстве вызывающего привилегированного процесса/потока) + (в ecx) размер соответствующей области данных или что-то в таком же духе; (b): имела подфункции - по одной для каждой структуры ядра KolibriOS.

Б. Проект интерфейса функции - замены SysFn09

Параметры для всех подфункций:
eax = номер функции
ebx = номер подфункции
ecx = номер слота потока (ecx = -1 - получить информацию о текущем потоке)
edx = размер буфера (*если требуется: если данные не умещаются - в буфер помещаются только начальный фрагмент)
esi = указатель на буфер (*если требуется)

Возвращаемые значения:

Для всех подфункций:
eax - код успешности операции (-1 - некорректные параметры(остальные регистры неизменны); 1 - слот не занят(остальные регистры неизменны); 0 - успешное выполнение операции(регистры содержат корректные данные))

Для подфункции 0 (основная информация об окне потока)
ebx = координата окна потока по оси x
ecx = координата окна потока по оси y
edx = размер окна потока по оси x
esi = размер окна потока по оси y


Для подфункции 1 (основная информация о клиентской области)
ebx = координата начала клиентской области по оси x
ecx = координата начала клиентской области по оси y
edx = ширина клиентской области
esi = высота клиентской области

Для подфункции 2 (дополнительная информация об окне и оконном стеке)
ebx = позиция окна потока в оконном стэке
ecx (точнее - bl)= состояние окна - битовое поле (бит 0 (маска 1): окно максимизировано ;бит 1 (маска 2): окно минимизировано в панель задач ; бит 2 (маска 4): окно свёрнуто в заголовок )
edx = (не имеет отношения к запрошенному потоку) номер слота потока, окно которого находится в оконном стэке в позиции ecx [примечание: честно говоря, я не понимаю смысла этого текста - просто скопировал пояснение из документации SysFn09]
esi = (не имеет отношения к запрошенному потоку) максимальный номер слота потока

Для подфункции 3 (основная информация о потоке)
ebx (точнее - al)= состояние слота потока:
0 = поток выполняется
1 = поток приостановлен
2 = поток приостановлен в момент ожидания события
3 = поток завершается в результате вызова функции -1 или насильственно как следствие вызова подфункции 2 функции 18 или завершения работы системы
4 = поток завершается в результате исключения
5 = поток ожидает события
ecx = идентификатор (PID/TID)
edx = битовая маска событий данного потока (в соответствии с описанием SysFn40)
esi = использование процессора (сколько тактов в секунду уходит на исполнение именно этого потока)

Для подфункции 4 (основная информация о процессе:* требует указания буфера для имени процесса)
буфер данных = имя процесса
ebx = адрес процесса в памяти
ecx = размер используемой памяти - 1

Firewall, отличная идея. Зачастую процессу нужно узнать всего лишь один параметр (PID, например) и ради него приходится выделять целый килобайт памяти. Да и скорость работы таких программ как CPU, @panel должна, по идее, увеличится в разы, а код упростится.

Nasarus! Спасибо за поддержку!

Пока выжду 10 дней:
- это позволит мне привести в порядок результаты "второго тренировочного заезда" (см. соседнюю ветку данного форума);
- это позволит собрать критические замечания по поводу проекта интерфейса функции - альтернативы SysFn09;
- это позволит перехватить "право реализации" этой функции тому, кто сможет сделать предварительную рабочую версию этой функции за один вечер.

Есть одно пожелание - чтобы в подфункции 0 были самые важные данные о процессе (имя, PID/TID)

То есть Вы предлагаете что-то вроде:

Для подфункции 0 (основная информация о процессе:* требует указания буфера для имени процесса)
буфер данных = имя процесса
ebx = адрес процесса в памяти
ecx = размер используемой памяти - 1
edx = PID/TID потока (в последующем PID процесса)

Для подфункции 1 (основная информация о потоке)
ebx (точнее - al)= состояние слота потока:
...
eсx = битовая маска событий данного потока (в соответствии с описанием SysFn40)
edx = идентификатор (PID/TID)
esi = использование процессора (сколько тактов в секунду уходит на исполнение именно этого потока)

А остальные функции далее ...

P.S.

Кому что кажется более важным

Да, примерно так я и предлагал
P.S. Ну, как минимум, идентификатор - самая важная информация о процессе.

ebx = адрес процесса в памяти

Если это базовый адрес процесса, то он 0 для всех. Значение имело смысл до перехода к страничной памяти.

Тогда его надо чем-то заменить осмысленным, например,
- адресом директории страниц процесса (это в прицеле на будуще: привилегированный процесс может иметь желание читать данные из адресного пространства других процессов);
- физическим адресом первой страницы процесса;
...

(И соответственно определнить понятие "базовый адрес процесса")

Другой вариант - убрать из новой функции

Цитата: "Ну, как минимум, идентификатор - самая важная информация о процессе."

Если Вы имеете в виду PID/TID, то это пока имено TID - идентификатор потока. Насколько я понимаю, пока в KolibriOS идентификатора процесса нет. (Поэтому я пока и продублировал возврат этого значения в двух подфункциях.)