Jurgen wrote: ↑Mon Aug 14, 2023 1:10 am Есть какие то предположения у разработчиков ядра?

У dunkaist спросите. Он хорошо в ядре разбирается. Я бы помог, но ассемблер не знаю. Сложен слишком для меня.

И ещё, когда в конце года выпустишь новую версию, выложи исходники. Только надо менять лицензию, а то тебя Майки достанут. Ведь в лицензии MASM написано, что использовать его в проектах под GNU GPL нельзя. Либо MIT, либо BSD, либо свою писать.

И да. С KPG я согласен. Почему бы, не реализовать поддержку приложений из Windows 3.11?

Jurgen wrote: ↑Mon Aug 14, 2023 1:10 am Столкнулся с проблемой отладки. При достижении определенного размера проги, отладчик выдает ошибку (см. скрин) и отказывается работать.
Запускаю в mtdbg, отладчик coldbg выдает такую же ошибку.

Похоже размер моей отлаживаемой проги достиг какого-то предела (лимита) в недрах ядра.
Глянул исходники ядра, но не нашел явных ограничений по размеру отлаживаемой проги. Размер проги 207Кбт.

У меня не воспроизвелось, давай минимальный рабочий пример приложения.

Отбой, нашел причину.
При трассировке ядра (источника сообщений об исключениях sys32.inc) выяснилось, что уже после вызова функции 70,7 происходит нарушение доступа к памяти.
Но, так как процесс грузится как отлаживаемый, то сообщение об исключении идет к отлаживаемому процессу, а не в Board и не вызывает ошибку после вызова функции 70,7. Это ведет к заблуждению пользователя.

Причиной сбоя доступа к памяти оказалось ошибочное размещение метки в программе.

Месяца два назад мне нужно было добавить метку для командной строки I_PARAM. Так как в примерах в WebSVN не нашел как его ставить, то сделал это вот так:

db 'MENUET01' ; 8-байтный идентификатор MenuetOS
dd 1 ; версия заголовка (1 либо 2, см. док-ю)
dd START ; адрес первой команды
dd I_END ; размер программы
dd MEM ; количество памяти
dd STACKTOP ; адрес вершины стэка
dd I_PARAM ; адрес буфера для параметров командн. строки
dd 0 ; зарезервировано

;.......
;.......
I_END:
MEM:
I_PARAM rb 100h ; <-- НЕПРАВИЛЬНОЕ МЕСТОПОЛОЖЕНИЕ!!!!!!

Оказывается метка I_PARAM должна быть расположена перед меткой MEM:

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

Сейчас делаю интеграцию network функций 75... в ws2_32.dll винды и столкнулся с такой проблемой.
Как только запустил работу винды с сокетами у меня через минуту стала падать система Колибри из-за нехватки памяти в ядре.

Стал выяснять причину и обнаружил следующее:
в функции 75,1 при закрытии сокета не освобождается память сокета типа IP_TCP, если не было коннекта или интернет соединения.

Если вы для эксперимента в бесконечном цикле откроете сокет типа IP_TCP функцией 75, а потом сразу закроете, то через минуту грохнется система Колибри от нехватки памяти.

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

В итоге,чтобы не падала система Колибри, я у себя сделал правки в системный файл socket.inc.
Однако я не особо силен в интернет технологиях, поэтому и написал этот пост, чтобы узнать мнение авторов функций 75, правильно ли я сделал.

Короче, раньше было так (см. ниже скрин):
У меня создавался сокет по протоколу IP_PROTO_TCP и когда он сразу закрывался, то внутри функции 75,1 после проверки на SS_ISCONNECTED (см. socket.inc строка 767) поток просто выходит из процедуры без освобождения памяти, так как вызов функции socket_free закомментирован. (Наверно, по особым соображениям авторов)



Вот мои правки файла socket.inc (см. скрин). Однако, я не уверен что нужно после проверки условий всегда вызывать функцию socket_free, как показано на скрине.

Сейчас у меня Колибри не падает, но посмотрим что дальше будет с интернетом.




№№№№№№№№№№№№№№№№
P.S:
После просмотра алгоритма работы функций 75... у меня есть рацпредложение авторам этих функций.
Предлагаю в качестве ID номеров сокетов выдавать адреса структур данных сокета.
Эти адреса всегда будут уникальны в системе, т.к. никакая другая функция не получит этот адрес пока он не будет освобожден.
Если нужно чтобы ID номер сокета был положительным на выходе, то можно просто автоматом сбрасывать 31-ый бит в адресе, а потом восстановить.
В итоге не нужно проверять списки активных сокетов и упрощается алгоритм работы с данными.
№№№№№№№№№№№№№№№

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

1.) Чтобы окно нотепада могло перемещаться за пределы экрана как у винды, я изменил принцип создания окна.
Сначала создается прозрачное окно на весь экран и уже внутри этого прозрачного окна рисуется окно нотепада, что позволило перетаскивать окно нотепада за пределы экрана.

2.) При доводке функциональности меню нотепада простые пункты меню были сделаны.
Но когда начал реализовывать пункт меню Файл-Открыть то столкнулся с тем, что винда начала задействовать сервисы, драйверы и систему безопасности.
В начале я попытался обойтись созданием новых потоков для сервисов и отключить вызовы драйверов, но чем дальше в лес тем проблемнее.

Поэтому было решено пойти классическим путем запуска системы винды начиная с первого исполняемого файла, которое запускается в пользовательском режиме, убрав некоторые необязательные. (Winlogon Userinit)
Была выбрана такая схема последовательности запуска винды:
lsass.exe → services.exe → notepad.exe (или рабочий стол explorer.exe)

3.) Далее пришлось решать вопрос с базовой поддержкой запуска драйверов сразу, а не потом, как планировалось. После перебора вариантов остановился на таком.
WCore запускает драйверы в пользовательском режиме. Чтобы не столкнуться с исключениями, из-за применения привилегированных ассемблерных инструкций, основные базовые три драйвера ( ntoskrnl.exe, win32k.sys, hal.sys) по факту не запускаем, а замыкаем все их внешние функции на себя.
Для обеспечения работы драйверов пришлось дополнительно разрабатывать функции ntoskrnl.exe. Хорошо, что эти функции в большинстве случаев функционально повторяют функции ntdll

В итоге lsass.exe бодренько загрузил более десятка системных драйверов, а список функций этих трех драйверов составил более 100кБт в теле WCore.

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


4.) Далее разрабатывался механизм межпроцессорных коммуникаций, а также функции работы портов и каналов были переписаны с применением именованной памяти.


5.) Далее пришлось решать вопрос с обработкой фреймов исключений в селекторе fs:0.
По стандарту винды, при вызове программируемого исключения функцией NtRaiseException, делается перебор фреймов в списке по адресу fs:0 каждого отдельного потока.
В нашем случае в этом fs:0 будет список фреймов исключений от разных потоков с пересортицей и мусором, так как селектор не разделен между потоками.

После перебора вариантов остановился на таком:
а) По ИД потока получаем пределы стека потока
б) Начиная от текущей позиции в стеке и поднимаясь по стеку получаем фреймы исключений и обрабатываем их пока не произойдет переход по какому-то фрейму.


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


7.) Далее при отладке запуска файла services.exe возникла такая ситуация, что для корректной работы этого файла нужно заново переписывать функции, которые ранее уже мной переписаны и отлажены, под особенности коммуникации services.exe с сервисами.
Я не согласился с этим и поэтому, после изучения алгоритма работы services.exe, реализуется самостоятельная загрузка сервисов из списка в реестре.

Теперь схема последовательности запуска винды пока выглядит так:
lsass.exe → (Запуск сервисов из списка в реестре) → notepad.exe (или рабочий стол explorer.exe)


8.) Сейчас идет процесс отладки запусков сервисов и параллельно начата реализация функционала:
*по работе с интернетом ( ws2_32.dll)
*по удаленному вызову процедур ( rpcrt4.dll)


Выкладываю здесь архив на всякий случай - в нем весь черновик разработки.

Сколько времени у тебя на это ушло? Я хочу оценить скорость разработки чтобы понимать насколько я медленный в более простой задаче.

Vaicheslav97 wrote: ↑Wed Dec 20, 2023 9:10 pm Сколько времени у тебя на это ушло? Я хочу оценить скорость разработки чтобы понимать насколько я медленный в более простой задаче.

Старт реализации проекта с сентября 2021 года

Этот пост будет продолжением темы поста от дек 17, 2023

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

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


;""""""""""""""""""""""""""""""""""""""""
Действие пользователя
Если пользователь (приложение) желает обрабатывать исключения переполнения стека, то он создает в теле программы дополнительную область памяти для аварийного\резервного стека с размером, достаточным для обработки данного исключения.

Алгоритм действий пользователя:
1. Создает в заголовке программы дополнительное поле с меткой. (Например EXCEPT_STACKTOP)
2. Для метки EXCEPT_STACKTOP выделяется область памяти.
3. Ставит флаг 12 в маске обработки исключений стека в функции 68,24
4. При возникновении исключения с кодом 12 в аварийном стеке будет представлена нижеследующая инфа (см структуру EXCEPT_STACK)
5. Обработчик приложения делает то, что нужно и при завершении обработки этого исключения сбрасывает (обнуляет) бит занятости аварийного стека. (структура EXCEPT_STACK.LockAccess)


Ниже показан пример установки метки для аварийного\резервного стека: Пример выделения памяти для аварийного\резервного стека:
Продолжение следует......

Продолжение темы

;"""""""""""""""""""""""""""""""""""""""""""""
Алгоритм ядра системы Колибри
При возникновении исключения со стеком, по логике должно генерироваться исключение 12. Однако, из-за настроек (системы или процессора), при переполнении стека чаще всего генерируется исключение 14 (page fault).
У меня генерируется исключение 14 даже при явном применении команд типа push pushad со стеком.
Поэтому, при возникновении исключения 14, предлагаю сделать в ядре дополнительные проверки для корректного определения причины исключения.

Принцип проверки:
Перед базовым адресом стека всегда будет незанятая область памяти в 1000h и поэтому, если обращение к памяти было в пределах этого размера, то значит была попытка обратиться к несуществующей памяти стека.


Ниже предлагается:
1. Внедрить в файл sys32.inc (после метки IRetToUserHook:) код дополнительной проверки причины исключения. (см ниже)
2. Внести изменение в структуре APP_HEADER_01_ (добавить дополнительное поле - except_stack_top) в taskman.inc (см ниже)

Изменение в структуре APP_HEADER_01_

Код дополнительной проверки после метки IRetToUserHook:

Если не будет возражений, то я планирую через месяц внести этот код в SVN, а также прописать в справочнике по функциям sysfuncr.txt у функции 68,24 дополнительную инфу по исключениям


№№№№№№№№№№№№№
Примечание по коду проверки исключения 14

Библиотеки винды используют два варианта увеличения стека через исключение:
1. Простое переполнение в ходе использования стека
2. Динамическое выделение области памяти в стеке размером более чем в 1000h

Ниже показан пример процедуры динамического выделения памяти в стеке в модуле dmserver.dll
Так вот, при выделения памяти в стеке размером более чем 1000h, мой код может не определить это исключение, так как разница между адресом в регистре esp и адресом в регистре cr2 может составить более 1000h.

Для 100% определения исключений в стеке, нужно дополнительно определить по адресу в ESP базовый адрес памяти стека. И уже по базе памяти стека вычислять разницу с регистром cr2.

Я пока не нашел в ядре Колибри функцию определения базы памяти по его адресу. Видимо потом придется прописывать дополнительный код.
№№№№№№№№№№№

Jurgen wrote: ↑Sun Nov 12, 2023 5:30 am Сейчас делаю интеграцию network функций 75... в ws2_32.dll винды и столкнулся с такой проблемой.
Как только запустил работу винды с сокетами у меня через минуту стала падать система Колибри из-за нехватки памяти в ядре.

You got the basics right.
The reason socket_free is commented out is because stack is still unfinished.
There are some problems in the current design with thread-safety (locking) and possible use-after-free cases..

hidnplayr wrote: ↑Wed Jan 31, 2024 11:28 pm ...
There are some problems in the current design with thread-safety (locking) and possible use-after-free cases..

For causes of the use-after-free.

Сan be using fixed or dynamically signature (currentID) in the socket data.
When creating a socket, write the signature.
Before closing a socket, del the signature.
After received the socket from a user, check signature of the socket. If there isnt signature, then the socket isnt valid.

Jurgen wrote: ↑Fri Feb 02, 2024 7:15 am

hidnplayr wrote: ↑Wed Jan 31, 2024 11:28 pm ...
There are some problems in the current design with thread-safety (locking) and possible use-after-free cases..

For causes of the use-after-free.

Сan be using fixed or dynamically signature (currentID) in the socket data.
When creating a socket, write the signature.
Before closing a socket, del the signature.
After received the socket from a user, check signature of the socket. If there isnt signature, then the socket isnt valid.

Except this signature cannot be in the socket structure itself, because that in itself is also 'use after free'