Board.KolibriOS.org

Jurgen wrote: ↑Sat Dec 21, 2024 11:26 pm У меня вопрос к модератору:
При написании этого поста у меня сообщается, что я могу прикрепить здесь файл (файлы) с общим размером в 10Мбт.
Я попытался загрузить сюда файл ZIP с iso образом ядра Колибри v.2 со встроенным "монитором", для желающих протестировать этот монитор. Общий размер файла - 1,27Мбт.
Однако система не смогла полностью загрузить этот файл. Сообщает - "HTTP error".

Исправил

Гут. Тогда продолжим...

По поводу Монитора остается вопрос корректности его работы у разных ЦП, при числе кэшей у ЦП более 4х.

При желании, Вы можете у себя проверить корректность работы моего Монитора.. Для этого:
а) Скачать и запустить у себя iso образ ядра Колибри v.2 (см ссылку ниже)
б) После запуска системы Колибри посмотреть, есть ли «ложное» срабатывание Монитора с сообщением в Board. Для этого:
Запустить Board и нажать в нем кнопку «User”
Сообщение Монитора в Board в формате: «Thread CPU Usage more 5 sec. …....” через каждые 5 сек.
Если нет ложного срабатывания, тогда следующий пункт.


в) Перейти к минипроге CHECK_MONITOR:
(Нажать кн. «Меню» → Система → Файловые менеджеры → Eolite → В списке «Устройства» кликнуть на «CD-Rom ….” )


г) Запустить эту минипрогу в отладчике mtdbg:
(Кликнуть правой кнопкой мыши по файлу CHECK_MONITOR → Выбрать в подменю «Запустить с помощью....» → В появившемся окне кликнуть на кнопку «Обзор» → Дважды кликнуть по папке «DEVELOP” → В списке файлов найти файл “MTDBG” и дважды кликнуть по нему → Нажать на клавишу «G” → Нажать на клавишу. «Enter” и запустится программа в отладчике)

И проверить:
1) Появится ли .через 5 сек. сообщение в Board (Запустить Board и нажать кнопку «User”)
2) Если появится, то проверить в сообщении корректность указанного адреса «проблемного» места в минипроге и правильность значений регистров..

Вот так у меня работает Монитор (скрин) при 2х ядрах и 4х кэшей у ЦП.
Примечание:
1) Для Board я добавил справочное сообщение: cpu freguence ..(выделено красным) которое показывает реальную тактовую частоту вашего ЦП, вычисленное системой Колибри.
Вы можете сравнить это значение с прогой GHOST MONITOR
(Для запуска GHOST MONITOR кликнуть в трее на вертикальную шкалу в нижнем правом углу возле часов).
Будет несовпадение значений при превышении тактовой частоты ЦП более 3300МГц .

2) Поток №1 IDLE ядра Колибри игнорируется «Монитором» — иначе появлялось бы сообщение каждые 5 сек. при простое системы


Если что не так с моим «Монитором» , напишите здесь какой у вас процессор и желательно скрин сообщений Board — будем думать.


Удачи

Jurgen wrote: ↑Sat Feb 17, 2024 11:33 amЕсли разработчик ядра, драйвера или приложения желает обезопасить механизм обработки данных при обращении к памяти для записи/чтения (например, к памяти полученной от пользователя), то он может сделать следующие действия:
1.) Перед обращением к памяти, установить следующие данные для обработчика "контролируемых исключений" ядра:
- В регистр edi занести сигнатуру - текст 'EXPT'

What do you mean by 'обезопасить'? In protected mode we have virtual memory for that. If a thread accesses invalid memory, just return something like -EFAULT and/or kill it. If you want to handle exceptions, you can set exception handlers via sf68.24 or use the debug API via sf69. I don't know what you are trying to do, but it's definitely not about memory safety.

Changing the kernel logic because of the magic value in edi doesn't look good either. If some code is unlucky to have 'EXPT' in edi, it will fail because there is nothing meaningful in esi. In short, your change isn't compatible with existing code.

dunkaist wrote: ↑Thu Feb 27, 2025 5:12 am

Jurgen wrote: ↑Sat Feb 17, 2024 11:33 amЕсли разработчик ядра, драйвера или приложения желает обезопасить механизм обработки данных при обращении к памяти для записи/чтения (например, к памяти полученной от пользователя), то он может сделать следующие действия:
1.) Перед обращением к памяти, установить следующие данные для обработчика "контролируемых исключений" ядра:
- В регистр edi занести сигнатуру - текст 'EXPT'

What do you mean by 'обезопасить'? In protected mode we have virtual memory for that. If a thread accesses invalid memory, just return something like -EFAULT and/or kill it. If you want to handle exceptions, you can set exception handlers via sf68.24 or use the debug API via sf69. I don't know what you are trying to do, but it's definitely not about memory safety.

Changing the kernel logic because of the magic value in edi doesn't look good either. If some code is unlucky to have 'EXPT' in edi, it will fail because there is nothing meaningful in esi. In short, your change isn't compatible with existing code.

Это альтернативный вариант обработчика исключений (без использ функций) для применения в пользовательском режиме или в режиме ядра.
Если вы считаете что эта вещь вам не нужна, то вы можете удалить его. Мне все равно

It was me who approved your write access to the repository. It was me again who advocated for you in the telegram chat when you broke the network in this commit. If I wanted to remove your code, I would have already done so. I don't want this.

Your priority is the Windows emulation project, no problem at all. My priority is KolibriOS. Therefore I am obviously interested to understand how KolibriOS can benefit from another exception handling mechanism. If it's something useful not only for the emulator (even in perspective), then great. For example, thread priority is a common and useful feature in many OSes. Maybe this is the case for your exception handling mechanism too. Please, elaborate.

Do I understand correctly that the new mechanism breaks existing code which is unlucky to have edi='EXPT' just before exception? If yes, can this be implemented in a compatible manner?

You are an experienced engineer without a doubt. I would be happy if you not only explained what you have done for your emulator but also suggested the way other KolibriOS developers could use these features.

By the way, we have finally switched from svn to git. Due to spam bots, registration is currently done by hand. Let me know if you need an account. Alternatively, just show up in the chat.

dunkaist wrote: ↑Sun Mar 16, 2025 6:01 am It was me who approved your write access to the repository. It was me again who advocated for you in the telegram chat when you broke the network in this commit. If I wanted to remove your code, I would have already done so. I don't want this.

Your priority is the Windows emulation project, no problem at all. My priority is KolibriOS. Therefore I am obviously interested to understand how KolibriOS can benefit from another exception handling mechanism. If it's something useful not only for the emulator (even in perspective), then great. For example, thread priority is a common and useful feature in many OSes. Maybe this is the case for your exception handling mechanism too. Please, elaborate.

Вот в этом посте,http://board.kolibrios.org/viewtopic.php?p=80284#p80284 в постскриптуме, я предложил участникам проекта Колибри совместную разработку и развитие ядра Колибри.
Я там не увидел ни одного комментария в поддержку моего предложения.

Поэтому, во избежание нарушения «тонкой душевной организации» отдельных участников сообщества (из-за «поломки» чего либо в ядре при внесении правок), принято решение вести разработку ядра Колибри самостоятельно.

Пусть пользователь сам решает какой вариант ядра Колибри использовать для своих нужд.

Текущая ситуация меня устраивает более чем: - не нужно делать посты со скринами- объяснять, уговаривать, доказывать необходимость изменений в ядре и прочее. В итоге у меня остается больше времени на отдых и на другие дела.
Кроме Эмулятора я еще регулярно работаю с оплачиваемыми заказами по реверсингу, что занимает также много времени.

dunkaist wrote: ↑Sun Mar 16, 2025 6:01 am Do I understand correctly that the new mechanism breaks existing code which is unlucky to have edi='EXPT' just before exception? If yes, can this be implemented in a compatible manner?

Конечно, в теории, могут так сойтись обстоятельства, что возникнет такая «неприятность» в пользовательском режиме. Однако для режима ядра пока нет другой альтернативы обработки возникших исключений ( для корректного завершения обработки «некорректных» данных полученных от пользователя).
По поводу вашего вопроса о возможности найти «совместимый вариант», исключающий такую «неприятность» для пользовательского режима - Да, это возможно.
Потом у себя в ядре попробую варианты — пока для меня это неактуально.

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

dunkaist wrote: ↑Sun Mar 16, 2025 6:01 am By the way, we have finally switched from svn to git. Due to spam bots, registration is currently done by hand. Let me know if you need an account. Alternatively, just show up in the chat.

Спасибо за предложение, возможно в будущем воспользуюсь вашим приглашением в git.

По поводу Телеграмм: В моем регионе провайдер заблокировал возможность регистрации в Телеграмм.
А ввиду того, что Дурова «продавили» на сотрудничество с французкими спецслужбам, то видимо никогда не разблокирует.

Привет всем.

Как и обещал ранее, сообщаю текущее положение с проектом на конец 2025 года.
Инфа идет в последовательности, что пришлось делать по ходу реализации проекта с последнего моего поста здесь:

1. Сервисы Винды и его драйверы при обращении к функции выделения памяти иногда требовали выравнивания памяти выровненной в 0 по младшему word адресу. При игнорировании этого требования случались глюки в работе эмулятора.
Пришлось добавить опцию в функции 68,12 - (установка 31 бита у размера позволяет получить адрес памяти выровненный в 0 по младшему word) и разбираться с принципом\алгоритмом работы функции в ядре Колибри по выделении страниц памяти.

2. Так как эмулятору приходится интенсивно выделять именованную память для межпроц взаимодействий, и вследствие чего занимать много страниц памяти, сделано изменение в логике функции 68,22(23) выделения\освобождения именованной памяти — Теперь все хэндлы именованной памяти в процессе привязываются к главному потоку процесса. В следствие чего, все потоки в одном процессе имеют одинаковый адрес межпроцессной именованной памяти, что позволяет сэкономить страницы памяти и уменьшить нагрузку на чипсет.

3. Когда explorer.exe отрисовал рабочий стол Винды со всеми визуальными элементами то выяснилось, что у меня это занимает в ДВА раза больше времени чем у оригинала Винды!!! Несмотря на то, что Колибри и эмулятор работают под ассемблером, а оригинал под более медленным Си (с километрами кода).

Мне пришлось решать проблему медленности инициации рабочего стола Винды у эмулятора (иначе пропадает смысл в этом проекте по изготовлению продукта ускорения работы Винды), в частности:
3а) пересматривать алгоритмы и оптимальность работы процедур.
3б) распараллеливать загрузку сервисов Винды при инициации.

И все это пришлось переделывать три раза. При каждом разе время загрузки рабочего стола эмулятором сокращалось на 15-20 сек.
Причем применение приоритетов потоков помогало не сильно — в среднем скидывало дополнительно 2-3 сек.
В итоге добился скорости загрузки\отображения рабочего стола Винды в два и более раза быстрее чем у оригинала.


4. В ходе мероприятий по оптимизации загрузки (см. п.3) применил придуманный мной принцип с рабочим названием - ТриЭР (Распределение Разделяемых Ресурсов) для функции выделения\освобождения небольших кусков памяти при многопоточной работе приложений.
Я гуглил в инете по поиску реализации что-то подобного — не нашел. Если кто найдет — напишите здесь. Мне будет интересно почитать.

По классике у многопоточных приложений:
При обращении «рабочего потока» (РП) к «блоку кучи памяти» (БКП) для получения\освобождения, то РП ждет освобождения ресурса для монопольного доступа.

В моем случае:
Для получения памяти «рабочим потоком» (РП):
а) РП ищет в связанном списке БКП первый свободный БКП и получает память из кучи от этого БКП.
б) Если все БКП заняты то РП создает новый БКП с минимальным размером и получает память от нового БКП.

При попытке освободить память "рабочим потоком" (РП):
а) РП обращается к БКП, от которого ранее получил память, и если БКП свободен, то РП сразу освободит память.
б) Если БКП занят, то РП отправляет «потоку обработчику заданий» (ПОЗ) запрос на освобождение памяти и сразу уходит по своим делам.
в) Когда придет очередь работе ПОЗ, то они освобождают память по полученным заданиям от РП.

В Свою очередь «потоком-контролером» (ПоК):
1) БКП периодически проверяются ПоК на занятость. Если БКП свободен и не использовался более 10 сек., то ПоК освобождает БКП (удаляет из списка БКП).
2) Число «потоков обработчиков заданий» (ПОЗ) динамически меняется в зависимости от нагрузки:
- Если ПоК определит занятость всех ПОЗ, то он автоматом запустит новый поток ПОЗ (если не превышает лимита максимального числа ПОЗ)
- Если ПОЗ не найдет себе работу в течение 5-10 сек., то он сам автоматически закроется, если общее число ПОЗ более 2х.


При реализации вышеизложенных алгоритмов метода ТриЭР на языках высокого уровня ( на языке Си и прочие..) получится много километров кода и положительный эффект может быть неоднозначным.
Но если это реализовать на ассемблере, то буквально пары-тройки десятка дополнительных строк ассемблерного кода вполне достаточно, чтобы реализовать эти все алгоритмы.


5. На текущий момент идет процесс отладки генерации звука при отображении рабочего стола Винды и решается проблема с отображением в трее рабочего стола Винды иконки динамика.


6. После решения вышеизложенной проблемы со скоростью отображения рабочего стола Винды (см. п. 3) пришел к выводу, что нужно также немедленно решить вопрос с мультипроцесорностью (МП) ядра Колибри, для реализации этого проекта.
Потому-что в будущем получится такая ситуация:
Если юзер, который ничего не знает о проекте Колибри, из любопытства попытается запустить у себя на компе (8-32 процессорном) мой эмулятор, то юзер может не заметить повышения скорости загрузки рабочего стола Винды, так как Колибри использует только 1 процессор для работы.
И в итоге, у юзера будет разочарование от знакомства с проектом Колибри и с моим эмулятором..

Поэтому, мне придется в приоритетном порядке реализовать МП у ядра Колибри, прежде чем далее работать с эмулятором под Win7 -Win11.
Тем более, заодно нужно решить проблему ограничения общего числа потоков у Колибри (255 потоков), так как уже на пиках работы эмулятора общее число потоков превышает 190
(Также придется патчить прогу отладчик WinDbg, так как отладчик оперирует с ID потока размером в word а не dword)


В итоге, ближайшие скорректированные планы по этому проекту:
1.) Доделать демонстрационный вариант эмулятора. Демонстрационный вариант эмулятора это - Показ рабочего стола Винды и показ формы учетной записи, при клике на кнопку "ПУСК", и все.
(Примечание: Если зарегено несколько учетных записей у Винды, то эмулятор выберет учетную запись с наименьшими правами.)
Готовый результат планируется выложить здесь в виде файла для тестинга желающими: с ядром Колибри v.2 и эмулятором под Win XP v2

2.) Переделка ядра Колибри под неограниченное число потоков и патчинг отладчика WinDbg.
3.) Реализация МП в ядре Колибри. После тестирования результат выложу здесь для желающих потестить : файл с МП ядром Колибри v.2 и эмулятором под Win XP v2.
4.) Далее по плану работа с эмулятором под версии Win7 -Win11.


В завершение Поздравляю всех с наступающим 2026м Новым Годом!! Всем благ и добра