Page 2 of 3
Re: Koilbri box в Фантоме
Posted: Mon Sep 26, 2011 6:59 pm
by SoUrcerer
dzavalishin wrote:Привет.
Вопросы и предложения:
1. загрузка приложения: можно ли проигнорировать адрес стека и сделать стек просто выше, чем конец данных? Каков объём буферов имени программы и командой строки? Что туда пишется? Значит ли что-то номер версии формата в заголовке программы? Где-то проскакивала информация о том, что один из указателей заголовка смотрит на иконку приложения. Верно ли? Какой? Что с форматом иконки?
Возможно, некоторые приложения обращаются к стеку по непосредственному адресу.
Оба буфера длиной 256 байт, вроде бы ничего не меняли. Номер версии формата что-то значит.
3. думаю, полезно задокументировать фичу с отрицательными позициями окна (== отсчёт от правого края)
А есть такая фича?
4. у функции считывания информации о треде есть в возвращаемой структуре третье поле, которое номер слота процесса, которому принадлежит окно номер ECX. Скажите мне, что это реально не используется?
Не знаю, используется это или нет, но есть некоторая вероятность, что где-то и используется.
6. Какой сетевой (tcp/ip) API реально надо эмулировать - тот, что в документации, или новый?
Если хочется запускать приложения из ветки net - то, очевидно, новый. Сетевой веткой занимается hidnplayr (он из Бельгии, если я не ошибаюсь), он может дать комментарии по вопросам сетевой части
7. загружаемые драйвера я пока не трогал, не нашёл документации. где почитать?
На вики и в SDK есть статьи "Пишем драйвер". Что-то наверняка есть в папке docs в папке с исходниками ядра. К сожалению, с документацией у нас туго
Комментарии может дать Serge и возможно кто-то еще.
9. В чём считается загрузка CPU - каково максимальное значение (числа тиков)?
Документация по системной функции 9
+0: dword: использование процессора (сколько тактов в секунду уходит на исполнение именно этого потока)
10. не хочет ли сообщество стандартизовать коды возврата и внедрить их во все вызовы? Ноль в EAX вернуть несложно...
Интересная мысль, ИМХО. Нужно у сообщества спросить.
Re: Koilbri box в Фантоме
Posted: Mon Sep 26, 2011 7:21 pm
by SoUrcerer
Прошу прощения, что пишу несколько постов подряд, но длинную простыню текста, особенно из не очень связанных кусков, читать неудобно.
Смотрю на
http://code.google.com/p/phantomuserlan ... /kolibri.c
Понимаю, что это, вероятно, не самые новые исходники, и всё же.
Функция 0 более сложная. Она определяет окна разных типов, в том числе "прозрачные". Это может вызвать ряд артефактов.
Функция 4 предусматривает шрифт не просто разного начертания: один с постоянной шириной символа, другой - нет. Заданные жестко размеры символов в некоторых программах приведует к неправильному их отображению шрифтом 8x16.
Кроме 7й функции есть 65я и 73я, они гораздо функциональнее, производительнее и получают все большее распространение. Фактически новые программы, использующие графику, немыслимы без 65й как минимум.
70я функция используется почти каждой программой.
Каталогизированный список системных функций с описаниями есть тут:
http://wiki.kolibrios.org/wiki/SysFn-1/ru
Re: Koilbri box в Фантоме
Posted: Mon Sep 26, 2011 7:38 pm
by dzavalishin
Про 65 и 73 я знаю, список функций, конечно, прочёл не раз.
Просто я их делаю по факту потребности прикладной программой.
70-я там есть почти полностью, но пока тоже не могу проверить - пока что пробовал только board, но он почему-то передаёт пустой блок данных файлового запроса, в итоге это выглядит как попытка записать в файл 'MENUET01'
- пока не понимаю, почему...
Какой должен быть размер шрифта?
Re: Koilbri box в Фантоме
Posted: Mon Sep 26, 2011 7:49 pm
by SoUrcerer
В архиве с исходными кодами 0.7.7.0, если я не ошибаюсь, есть файлы шрифтов char.mt и char2.mt без сжатия - в текстовом формате.
Оба шрифта имеют высоту 9 пикселов, моноширинный имеет ширину 6 пикселов. Маленькие, конечно.
Re: Koilbri box в Фантоме
Posted: Mon Sep 26, 2011 9:31 pm
by Mario
dzavalishin
Привет.
Тут конечно отвечали уже, но как-то неполно. Попробую что-то дополнить.
загрузка приложения: можно ли проигнорировать адрес стека и сделать стек просто выше, чем конец данных?
Кроме адреса стека есть еще указатели на конец образа и конец адресного пространства приложения. Нужно учитывать что в другие адреса приложение может что-то писать и обычно адрес стека задан не просто так, а со злобным умыслом.
Где-то проскакивала информация о том, что один из указателей заголовка смотрит на иконку приложения. Верно ли? Какой? Что с форматом иконки?
Никакой иконки нет. Это задумывалось вероятно автором Menuet давным давно, но так и не было реализовано. Впоследствии я решил использовать пропадающее впустую поле как указатель на область с полным путем к запущенной программе.
видео через gs: - кто-то это реально использует, или фича неактуальна? (и почему 24-битный, а не aligned 32-bit цвет? - риторический вопрос)
После того как Kolibri перешла на FLAT модель памяти - это все неактуально. Подробности лучше у Serge узнавать, как он уже упоминал LFB_BASE.
у функции считывания информации о треде есть в возвращаемой структуре третье поле, которое номер слота процесса, которому принадлежит окно номер ECX. Скажите мне, что это реально не используется?
Функция 9 используется многими программами и менять ее структуру быть ССЗБ.
Какую версию ядра мне лучше отдавать? Сейчас 0.7.7.0, так как я ориентируюсь на него.
Пока не вышел следующий дистрибутив остается 0.7.7.0
Почему 12.1 (начать перерисовку) убивает баттоны? За что??! Где вообще почитать про логику работы графики - обязано ли приложение звать 12.1 и 12.2? Если нет - зачем они?
Геноцид был еще автором Menuet предусмотрен, зачем не спрашивали - просто наследовали.
"-Что ты делаешь сын?
-Наследую тебя отец!" WarCraft3
Без 12.2 окно не будет изменять свое положение - проверено на опыте.
Логику работы можно прочитать в основном в коде ядра - как уже говорилось документации у нас мало.
не хочет ли сообщество стандартизовать коды возврата и внедрить их во все вызовы? Ноль в EAX вернуть несложно...
Лично я не хочу - это куча лишней работы по переписыванию over 200 программ, либо код раздуется если использовать хитрые обертки.
Re: Koilbri box в Фантоме
Posted: Mon Sep 26, 2011 9:46 pm
by Mario
А вообще есть вот такая информация на форуме
Ядро - концепция работы
Re: Koilbri box в Фантоме
Posted: Tue Sep 27, 2011 7:26 am
by Mario
Однакож 4 целых поста в ЖЖ об ОС которая "не надо" и как результат пишется эрзац колибри-вайн.
Re: Koilbri box в Фантоме
Posted: Tue Sep 27, 2011 8:00 am
by SoUrcerer
Mario, Колибри "не надо" пока не попробуешь. Когда я ее на Линукс-фесте в индивидуальном порядке показывал, до нажатия enter в загрузчике высказывались предположения "Оно же на ассемблере, будет тормозить" и "Да у них даже картинки посмотреть нельзя".
Re: Koilbri box в Фантоме
Posted: Tue Sep 27, 2011 8:13 am
by dzavalishin
Mario wrote:
Тут конечно отвечали уже, но как-то неполно. Попробую что-то дополнить.
загрузка приложения: можно ли проигнорировать адрес стека и сделать стек просто выше, чем конец данных?
Кроме адреса стека есть еще указатели на конец образа и конец адресного пространства приложения. Нужно учитывать что в другие адреса приложение может что-то писать и обычно адрес стека задан не просто так, а со злобным умыслом.
Я догадываюсь. Но вопрос был не в том, чтобы залудить стек куда попало, а в том, чтобы просто выделить для него ещё памяти, поверх той, что запрошена. Впрочем, это не будет работать, если приложение реально пользуется вызовом brk (64), так что вопрос снят.
Mario wrote:
у функции считывания информации о треде есть в возвращаемой структуре третье поле, которое номер слота процесса, которому принадлежит окно номер ECX. Скажите мне, что это реально не используется?
Функция 9 используется многими программами и менять ее структуру быть ССЗБ.
Вопрос был не про функцию, а про конкретное поле, которое я лично рекомендовал бы объявить как deprecated, и - если оно реально надо - ввёл бы отдельный сисколл. Напомню - функция в целом получает данные о треде, а именно ЭТО поле - об окне, что как-то диковато.
Mario wrote:
не хочет ли сообщество стандартизовать коды возврата и внедрить их во все вызовы? Ноль в EAX вернуть несложно...
Лично я не хочу - это куча лишней работы по переписыванию over 200 программ, либо код раздуется если использовать хитрые обертки.
Зачем? Я предлагаю стандартизовать в ядре метод возврата кода результата, а уж использовать его в каждой программе - дело опциональное. К сожалению, ни одного регистра, который был бы свободен во всех вызовах, я не нашёл, так что простого способа генерализовать API не вижу. Вижу такой вариант - если нить желает, она может специальным вызовом установить адрес переменной, в которую после каждого системного вызова будет помещаться код возврата. Коды возврата стандартизовать и возвращать в каждом сисколле, если переменная данным тредом установлена. Для ядра Колибри это пара команд на функцию.
Re: Koilbri box в Фантоме
Posted: Tue Sep 27, 2011 8:15 am
by dzavalishin
Я видел, спасибо. Я тут почти всё прочёл, что есть существенного.
Re: Koilbri box в Фантоме
Posted: Tue Sep 27, 2011 8:18 am
by dzavalishin
Mario wrote:Однакож 4 целых поста в ЖЖ об ОС которая "не надо" и как результат пишется эрзац колибри-вайн.
Я всегда знаю, зачем я что-то делаю.
Re: Koilbri box в Фантоме
Posted: Tue Sep 27, 2011 8:20 am
by SoUrcerer
Я тут почти всё прочёл, что есть существенного.
o_O тут сотни две существенных тем, ИМХО. Может, они к текущим вопросам и не относятся, но они есть.
Re: Koilbri box в Фантоме
Posted: Tue Sep 27, 2011 8:52 am
by Mario
Дима мой старший камрад (который упоминается в подписи) как бы намекает, что форум Димой читается очень давно.
Re: Koilbri box в Фантоме
Posted: Tue Sep 27, 2011 1:14 pm
by dzavalishin
Не очень. Но - я быстро читаю, пользуюсь поиском и знаю, что искать. Кроме того, у меня на даче есть gprs, достаточный, чтобы читать форум.
Ещё комментарий по API:
Вызов IPC, конечно, довольно изящен, но вынуждает поллить на предмет освобождения места или отпирания флажка. Может быть, добавить вызовы
ipc_send_blocking( void *data, size_t size, pid_t pid ) - не возвращается, пока не пошлёт и
ipc_recv_blocking( void *data, size_t size, size_t *recv_size, tid_t *tid )?
при этом они могут работать на той же самой структуре данных, если она определена (тогда будут совместимы со старыми вызовами), или на ядерной синхронизации - тогда не нужно выделенного буфера в приложении...
в обоих случаях поллинг отменяется и в приложении не нужно думать ни о чём
Re: Koilbri box в Фантоме
Posted: Tue Sep 27, 2011 1:18 pm
by Mario
К сожалению я в терминологии IPC плохо подкован - к стыду своему даже Таненбаума так и не дочитал.
Может чего Serge тут ответит - он обычно занимается передиранием всякого разного из *nix.