[ON] 86 выпуск новостей проекта ReactOS

Обсуждение новостей, соответствующих тематике форума

Модератор: Модераторы разделов

Аватара пользователя
rssbot
Бот
Сообщения: 6000
ОС: gnu/linux

[ON] 86 выпуск новостей проекта ReactOS

Сообщение rssbot »


Доступен перевод 86 выпуска новостей проекта ReactOS, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003). Прогресс в использовании компилятора MSVC Код ReactOS теперь может быть полностью собран с использованием компилятора Microsoft, но работать после такой компиляции операционная система пока ещё не способна. Тимо Кройцер (Timo Kreuzer) уже устранил несколько ошибок, среди которых повреждение метаданных файловой системы, приводившее к неработоспособности загрузчика freeldr. На платформах x86/x64 в процессе начальной загрузки в таблицу FAT c диска считывается загрузочный сектор, который должен быть загружен в достаточно высокие адреса, чтобы дальнейшее чтение freeldr в память позже не перезаписало бы эту таблицу. К сожалению, скомпилированная в MSVC версия freeldr занимает больше места, чем при компиляции с использованием GCC, что приводило к перезаписи таблицы FAT. Когда начальный загрузчик пытался запросить таблицу FAT, чтобы понять, нужно ли загрузить ещё что-то, он получал код freeldr вместо данных и предполагал, что необходимо загрузить дополнительные данные. Однако попытка использовать данные freeldr в качестве инструкции по загрузке, приводила к выводу ошибки и невозможности загрузить freeldr. Тимо устранил эту проблему, изменив адреса, куда загружается таблица FAT, чтобы гарантировать цельность данных при использовании файлов, скомпилированных с помощью MSVC. Другая проблема, связанная с файловой системой, была найдена в драйвере именованного канала (pipe). Драйвер поддерживает связанный список клиентских блоков управления (CCB), доступ к которому синхронизируется с использованием блокировки (lock). Однако существовал способ получить доступ к CCB без установки блокировки, что могло привести к эффекту гонки (race condition). Например, при определенном стечении обстоятельств один поток мог удалить запись в списке CCB, но ссылка на этот удаленный элемент могла в это время использоваться в другом потоке. Решение Тимо состояло в использовании счетчика ссылок, с последующим отслеживанием числа активных экземпляров ссылок к элементам CCB, чтобы препятствовать удалению еще занятых элементов CCB. Эта проблема также существовала и в сборке GCC, но была более достоверно воспроизведена в сборке MSVC. Устранение ошибок сети Хрупкость сетевого стека ReactOS иногда трудно понять не-разработчикам, но список проблем, который был недавно разрешен Камероном Гутманом (Cameron Gutman), должен дать представление о том, как много частей работало не правильно. Камерон обратил свое внимание на то, что многие сетевые тесты завершаются провалом. В результате трассировки некоторых сбойных тестов было выявлено использование некорректной семантики при работе с кодом обработки событий. Если программа сообщает ОС, что она ожидает определенное событие, но событие при этом было уже инициировано или инициировано прежде, чем ОС фактически вызывает функцию ожидания, ОС, как предполагается, сразу запускает программу, как только будет выполнен вызов ожидания события. Это не было сделано, что приводило к тому, что запрашивающие уведомление о событии программы в некоторых ситуациях зависали, прежде, чем могли сделать что-либо еще. Другая проблема с событиями связана с неправильной установкой полномочий для событий. События обычно создаются с уровнем разрешения EVENT_ALL_ACCESS. Однако, когда программа попыталась получить доступ к событию, код ОС пытается получить доступ к событию с уровнем разрешения FILE_ALL_ACCESS. Это не одно и то же: у FILE_ALL_ACCESS есть несколько полномочий, которых нет у EVENT_ALL_ACCESS, что должно приводить к ошибке доступа. С этим исправлением будет налажена отправка сигналов о наступлении событий, и приложения, которые ранее зависли на сетевых запросах, теперь должны работать нормально. Помимо уведомления о событиях сетевой активности, было найденоо несколько серьёзных семантических ошибок в обработке соединения TCP, затрагивающих несколько частей сетевого стека. Функции recvfrom и sendto обрабатывали соединения TCP в таком виде, как если бы они были соединениями UDP. Из-за этого такие функции просто не работали. Единственной причиной, по которой это не затрагивало большинство людей, является немногочисленность приложений, использующих функции recvfrom и sendto с соединениями TCP, для которых обычно используются функции recv и send. Как ни странно, recv не работал правильно с соединениями UDP, и снова странность работоспособности объясняется тем, что большинство приложений использует recvfrom для UDP. Исправление должно помочь справится с теми случаями, когда приложения не соблюдали выше описанные негласные правила. Еще один набор проблем был связан с особенностями завершения работы сетевых соединений в используемой в ReactOS библиотеке oskittcp. Протокол "рукопожатия" (handshake) в TCP предусматривает использование пакетов с флагом FIN для информирования удаленной стороны о завершении передачи данных. Вызов функции "shutdown(SD_SEND)" генерирует пакет FIN, но должен все еще оставить соединение открытым для чтений. К сожалению, библиотека oskittcp не делала этого и полностью закрывала сокет, что приводит к невозможности выполнения операций чтения из сокета после вызова функции завершения отправки данных. Заключительная проблема, которую устранил Камерон, также была связана с oskittcp. В частности, из-за данной библиотеки не происходило информирование ОС о сбоях соединения. После решения данной ошибки сетевой стек ReactOS проходит значительно больше тестов и стал более пригоден к использованию. Одновременно, проблемы в oskittcp подталкивают разработчиков к миграции на альтернативную библиотеку lwip.


Источник: http://www.opennet.ru/opennews/art.shtml?num=31307


View the full article
Спасибо сказали: