Board.KolibriOS.org

Здравствуйте!
Установил KolibriOS. Опробовал. Заинтересовался.
Скачал мануал "Документация по программированию в KolibriOS". Стал изучать, но вопросов появилось очень много.

Потом нашёл SDK. Изучил примеры. Потом в wiki прочитал про функционирование ядра — стало чуть понятнее. Но, тем не менее, осталась куча вопросов, например, что происходит во время загрузки программы (что куда загружается, как создаётся поток), про память и стек (например, бэйсик для Menuet почему-то начинает программу с mov esp, %вершина стека% и определяет громадные значения для памяти приложения — как должно быть на самом деле и от чего зависит я не понял).

Постоянно перегружаться, чтобы проверить, совсем неудобно. Я узнал про эмулятор. Стало проще. Но он (не удивительно) или не полностью эмулирует, или не так как надо, или что-то не поддерживает. Поэтому всё равно приходится перегружаться, но с эмулятором гораздо меньше.

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

Недавно я написал 2 программки: одна выдаёт информацию о потоке с активным окном, а другая — о потоке, окно которого под указателем мыши.
Теперь ещё прибавилось вопросов:
в мануале написано "Обычные приложения размещаются в памяти по адресу 0x60400000" — когда я получаю информацию о потоке, то адрес процесса в памяти = 0, и приложение CPU тоже так показывает для всех потоков. Как должно быть на самом деле?

Далее, "11 байт: имя процесса..." — здесь эмулятор (если я не ошибся) ведёт себя не так, как Kolibri. А как на самом деле? То есть, если имя меньше 11 символов, то ставится завершающий 0 или заполняется пробелами? И всегда ли это происходит одинаково?

Ещё эмулятор про клиентские размеры выдавал какую-то чепуху.

Потом я загрузил Kolibri. Запустил свои программки. И узнал ещё чуть больше. Например (если это не моя ошибка), сам рабочий стол, поток ICON, со временем менял свой ID, а это, согласно мануалу, невозможно: "идентификаторы монотонно растут", "не изменяются со временем для заданного потока", "Идентификатор потока не может быть назначен другому потоку даже после завершения первого." Значит этот поток завершался, а вместо него запускался его "близнец"(ну или он же перезапускался просто).

А что происходит во время переключения потоков? В эмуляторе иногда показывало "OS/IDLE", в Kolibri не заметил такого. (я тут имею ввиду, тот промежуток, когда "от первого потока мы ушли уже, а второй ещё как бы не успел активироваться")

Теперь вопрос про основной цикл прораммы. Если нужно просто реагировать на события — то я использую функцию ожидания события.
Но как быть, если нужно и реагировать на события и кроме этого ещё постоянно что-то выполнять? Я решил переключаться на следующий поток (эмулятор опять сказал, что не знает такую функцию). Пусть система сама решит, какой следующий, и когда вернуться опять к этому (но пока, насколько я понял, для всех потоков время одинаковое). Или же, можно было ждать событие некоторое время. Как в этом случае было бы правильнее делать (ждать или переключаться)?

Когда я (всё-таки) сделал скриншот моих программок, скриншотер сделал что-то с рабочим столом. От чего это так? Может, надо было что-то ещё настроить или я что-нибудь не то нажал?

Может ли Kolibri работать с PATA? У меня сначала не определялись диски, потом я в BIOS оставил только SATA(а было PATA+SATA).

0CodErr wrote:Здравствуйте!
Установил KolibriOS. Опробовал. Заинтересовался.
Скачал мануал "Документация по программированию в KolibriOS". Стал изучать, но вопросов появилось очень много.

Добро пожаловать попробую ответить на всё, что смогу.

(например, бэйсик для Menuet почему-то начинает программу с mov esp, %вершина стека% и определяет громадные значения для памяти приложения — как должно быть на самом деле и от чего зависит я не понял).

Если ты про бейсик от Ярека - то он морально устарел и никуда не годится. Почему автор сделал так, а не иначе - нужно спросить у автора.

Постоянно перегружаться, чтобы проверить, совсем неудобно. Я узнал про эмулятор. Стало проще. Но он (не удивительно) или не полностью эмулирует, или не так как надо, или что-то не поддерживает. Поэтому всё равно приходится перегружаться, но с эмулятором гораздо меньше.

Я использую qemu с расшаренными папками. Загружается за пару секунд. Еще можно использовать tftp - быстро и не нужно перезапускать ОС в эмуляторе.

в мануале написано "Обычные приложения размещаются в памяти по адресу 0x60400000" — когда я получаю информацию о потоке, то адрес процесса в памяти = 0, и приложение CPU тоже так показывает для всех потоков. Как должно быть на самом деле?
Далее, "11 байт: имя процесса..." — здесь эмулятор (если я не ошибся) ведёт себя не так, как Kolibri. А как на самом деле? То есть, если имя меньше 11 символов, то ставится завершающий 0 или заполняется пробелами? И всегда ли это происходит одинаково?

Попробуй свои программы в ночной сборке - многое могло измениться. Если имя меньше 11 символов, то, как я понимаю, должно забиваться 0x00.

Ещё эмулятор про клиентские размеры выдавал какую-то чепуху.

Использовать эмулятор для разработки программ не стоит, на самом деле.

Потом я загрузил Kolibri. Запустил свои программки. И узнал ещё чуть больше. Например (если это не моя ошибка), сам рабочий стол, поток ICON, со временем менял свой ID, а это, согласно мануалу, невозможно: "идентификаторы монотонно растут", "не изменяются со временем для заданного потока", "Идентификатор потока не может быть назначен другому потоку даже после завершения первого." Значит этот поток завершался, а вместо него запускался его "близнец"(ну или он же перезапускался просто).

Каждая иконка - это поток ICON. Их два десятка с одним именем. Разумеется, у них разные идентификаторы.

Теперь вопрос про основной цикл прораммы. Если нужно просто реагировать на события — то я использую функцию ожидания события.
Но как быть, если нужно и реагировать на события и кроме этого ещё постоянно что-то выполнять? Я решил переключаться на следующий поток (эмулятор опять сказал, что не знает такую функцию). Пусть система сама решит, какой следующий, и когда вернуться опять к этому (но пока, насколько я понял, для всех потоков время одинаковое). Или же, можно было ждать событие некоторое время. Как в этом случае было бы правильнее делать (ждать или переключаться)?

Мне кажется, если нужна максимальная производительность программы, то можно делать так:
1) проверка события (а события помещаются в буфер событий)
2) реакция на события, если есть
3) вычисления
4) Переход к п.1
Все остальное должна брать на себя система.

Когда я (всё-таки) сделал скриншот моих программок, скриншотер сделал что-то с рабочим столом. От чего это так? Может, надо было что-то ещё настроить или я что-нибудь не то нажал?

Попробуй свежую ночную сборку. Возможно, проблемы с самим скриншутером.

Привет.
Много вопросов, задавай по одному и пользуйся поиском по форуму. Основная инфа - в коде, ну и здесь кое-что можно найти.
Все мануалы и Вики (увы!) страдают и оставляют желать.
Что за "эмулятор" такой кривой?
Какая версия ядра?
"Обычные приложения размещаются в памяти по адресу 0x60400000" - это очень старая адресная модель; сейчас линейные адреса приложения начинаются с 0.

SoUrcerer wrote: Если ты про бейсик от Ярека - то он морально устарел и никуда не годится. Почему автор сделал так, а не иначе - нужно спросить у автора.

То есть, самому esp устанавливать нет необходимости? Только указать значение в хедере, а дальше система уже сама всё сделает?
Я думаю, автор делал так для "универсальности" своего транслятора. Ещё где-то в исходниках(наверное, уже устаревших) было "MENUET00" и "Version 38" в заголовке.

SoUrcerer wrote: Каждая иконка - это поток ICON. Их два десятка с одним именем. Разумеется, у них разные идентификаторы.

Я не совсем правильно выразился... В общем, я проверил своей программкой каждый ICON(саму иконку на рабочем столе), а когда отводил мышь от иконки на рабочий стол, то вот этот ID рабочего стола менялся.
Я понял, что ICON — поток иконки, а иконок несколько.

SoUrcerer wrote: Мне кажется, если нужна максимальная производительность программы, то можно делать так:
1) проверка события (а события помещаются в буфер событий)
2) реакция на события, если есть
3) вычисления
4) Переход к п.1
Все остальное должна брать на себя система.

Если проверять без ожидания и не переключаться на другой поток, то это сильнее грузит систему. Теперь я попробовал ждать в течение определённого времени(вместо прежней проверки и переключения потока) — стало меньше грузить систему.

art_zh wrote:Привет.
Много вопросов, задавай по одному и пользуйся поиском по форуму. Основная инфа - в коде, ну и здесь кое-что можно найти.
Все мануалы и Вики (увы!) страдают и оставляют желать.

Ну я, например, в Вики тоже многое нашёл.
Раньше можно было здесь http://kolibrios.org/ru/repos/ найти исходники и на Редмайне ещё было. А теперь куда всё делось?

art_zh wrote: "Обычные приложения размещаются в памяти по адресу 0x60400000" - это очень старая адресная модель; сейчас линейные адреса приложения начинаются с 0.

То есть, и у системы, и у приложений(без исключений) память с нуля?

Я понял, что ICON — поток иконки, а иконок несколько.

Поставь галку в CPU и увидишь все запущенные потоки. ICON многопоточное приложение.

Если проверять без ожидания и не переключаться на другой поток, то это сильнее грузит систему.

Функции 10, 11, 23.

То есть, и у системы, и у приложений(без исключений) память с нуля?

http://wiki.kolibrios.org/wiki/Kernel/ru
http://ru.wikipedia.org/wiki/Плоская_модель_памяти
http://en.wikipedia.org/wiki/Flat_memory_model

0CodErr wrote:В общем, я проверил своей программкой каждый ICON(саму иконку на рабочем столе), а когда отводил мышь от иконки на рабочий стол, то вот этот ID рабочего стола менялся.

Рабочий стол - не приложение. Есть обои, которые рисует система, и есть иконки и панель. Иконки и панель - приложения. Стол - нет.

0CodErr wrote:Раньше можно было здесь http://kolibrios.org/ru/repos/ найти исходники и на Редмайне ещё было. А теперь куда всё делось?

http://websvn.kolibrios.org

SoUrcerer wrote: http://websvn.kolibrios.org

Спасибо!

SoUrcerer wrote: Рабочий стол - не приложение. Есть обои, которые рисует система, и есть иконки и панель. Иконки и панель - приложения. Стол - нет.

Но тогда идентификатор чего это мог быть(да ещё и менялся)?

Mario wrote: http://wiki.kolibrios.org/wiki/Kernel/ru
http://ru.wikipedia.org/wiki/Плоская_модель_памяти
http://en.wikipedia.org/wiki/Flat_memory_model

Спасибо, с памятью разобрался.

Mario wrote: Функции 10, 11, 23.

Что они делают — я понял. Мне не ясно, как лучше: ждать по времени или же сразу проверять и потом переключать поток(если не переключаю — нагрузка этого потока больше)?

Если сразу переключать, то увеличится время отклика. Вообще ф.11 и ф.23 отличаются лишь наличием вызова паузы в 23.
Если нет жесткой необходимости проверять что-то кроме приходящих приложению событий, то нужно использовать ф.10.
Если есть необходимость обрабатывать что-то еще кроме системных событий, то можно использовать ф.23 - к примеру zSea в режиме показа слайд-шоу использует ее, да и при демонстрации анимированного GIF.

Но тогда идентификатор чего это мог быть(да ещё и менялся)?

Зачем требовать от людей развитого скилла телепатия? Где код по которому можно сделать выводы?

Mario wrote:Если сразу переключать, то увеличится время отклика.

Когда я использовал ф.11 и переключение потока — увеличивалось только потребление CPU, а не время отклика(я, по крайней мере, этого не заметил).

Mario wrote: Если есть необходимость обрабатывать что-то еще кроме системных событий, то можно использовать ф.23...

Скорее всего, то, что нужно. У меня в этом случае и потребление CPU меньше.

Mario wrote:

Но тогда идентификатор чего это мог быть(да ещё и менялся)?

Зачем требовать от людей развитого скилла телепатия? Где код по которому можно сделать выводы?

Там суть в том, чтобы отображать информацию о потоке, над окном которого указатель мыши.
Если рабочий стол потоком не является, то когда мышь «уходит» с ICON — она оказывается «не над чьим окном». Вероятно, поэтому возвращаются разные идентификаторы(они просто не имеют смысла).

Если мсье задумал написать вирус - я больше помогать не буду. Другие могут считать иначе и помогать.

Mario wrote:Если мсье задумал написать вирус...

??????

http://wiki.kolibrios.org/wiki/SysFn09/ru

0CodErr wrote:

Mario wrote:Если мсье задумал написать вирус...

??????

Если это не так, то добро пожаловать. Просто ломать всегда проще чем делать - даже если это бетонный антитермоядерный бункер. Прецеденты были.

Будет ли происходить перерисовка, если окно свёрнуто в заголовок?
Моя программка отображает увеличенный участок экрана под указателем мыши и показывает RGB-цвет точки. Так вот, если её свернуть в заголовок, то будет ли она пытаться перерисовывать?

Если специально не отлавливать на уровне алгоритма, то в типичном случае окно перерисовывается со всеми элементами, но код ядра отсекает и не выводит элементы (примитивы) находящиеся за текущей границей окна.
З.Ы. Судя по скриншоту - работает драйвер ATI.