Добро пожаловать попробую ответить на всё, что смогу.0CodErr wrote:Здравствуйте!
Установил KolibriOS. Опробовал. Заинтересовался.
Скачал мануал "Документация по программированию в KolibriOS". Стал изучать, но вопросов появилось очень много.
Если ты про бейсик от Ярека - то он морально устарел и никуда не годится. Почему автор сделал так, а не иначе - нужно спросить у автора.(например, бэйсик для Menuet почему-то начинает программу с mov esp, %вершина стека% и определяет громадные значения для памяти приложения — как должно быть на самом деле и от чего зависит я не понял).
Я использую qemu с расшаренными папками. Загружается за пару секунд. Еще можно использовать tftp - быстро и не нужно перезапускать ОС в эмуляторе.Постоянно перегружаться, чтобы проверить, совсем неудобно. Я узнал про эмулятор. Стало проще. Но он (не удивительно) или не полностью эмулирует, или не так как надо, или что-то не поддерживает. Поэтому всё равно приходится перегружаться, но с эмулятором гораздо меньше.
Попробуй свои программы в ночной сборке - многое могло измениться. Если имя меньше 11 символов, то, как я понимаю, должно забиваться 0x00.в мануале написано "Обычные приложения размещаются в памяти по адресу 0x60400000" — когда я получаю информацию о потоке, то адрес процесса в памяти = 0, и приложение CPU тоже так показывает для всех потоков. Как должно быть на самом деле?
Далее, "11 байт: имя процесса..." — здесь эмулятор (если я не ошибся) ведёт себя не так, как Kolibri. А как на самом деле? То есть, если имя меньше 11 символов, то ставится завершающий 0 или заполняется пробелами? И всегда ли это происходит одинаково?
Использовать эмулятор для разработки программ не стоит, на самом деле.Ещё эмулятор про клиентские размеры выдавал какую-то чепуху.
Каждая иконка - это поток ICON. Их два десятка с одним именем. Разумеется, у них разные идентификаторы.Потом я загрузил Kolibri. Запустил свои программки. И узнал ещё чуть больше. Например (если это не моя ошибка), сам рабочий стол, поток ICON, со временем менял свой ID, а это, согласно мануалу, невозможно: "идентификаторы монотонно растут", "не изменяются со временем для заданного потока", "Идентификатор потока не может быть назначен другому потоку даже после завершения первого." Значит этот поток завершался, а вместо него запускался его "близнец"(ну или он же перезапускался просто).
Мне кажется, если нужна максимальная производительность программы, то можно делать так:Теперь вопрос про основной цикл прораммы. Если нужно просто реагировать на события — то я использую функцию ожидания события.
Но как быть, если нужно и реагировать на события и кроме этого ещё постоянно что-то выполнять? Я решил переключаться на следующий поток (эмулятор опять сказал, что не знает такую функцию). Пусть система сама решит, какой следующий, и когда вернуться опять к этому (но пока, насколько я понял, для всех потоков время одинаковое). Или же, можно было ждать событие некоторое время. Как в этом случае было бы правильнее делать (ждать или переключаться)?
1) проверка события (а события помещаются в буфер событий)
2) реакция на события, если есть
3) вычисления
4) Переход к п.1
Все остальное должна брать на себя система.
Попробуй свежую ночную сборку. Возможно, проблемы с самим скриншутером.Когда я (всё-таки) сделал скриншот моих программок, скриншотер сделал что-то с рабочим столом. От чего это так? Может, надо было что-то ещё настроить или я что-нибудь не то нажал?