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 года