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-ый бит в адресе, а потом восстановить.
В итоге не нужно проверять списки активных сокетов и упрощается алгоритм работы с данными.
№№№№№№№№№№№№№№№