ROS Newsletter86

Выпуск новостей ReactOS №86

• Публикация в архиве

Достижения в поддержке компилятора MSVC

Теперь ReactOS полностью может быть собрана с использованием компилятора от Microsoft, но работать полученная таким образом операционная система пока не способна. Тимо Кройцер (Timo Kreuzer) уже устранил несколько возникших ошибок, таких например, как повреждения метаданных файловой системы, приводившие к сбою загрузки freeldr. На платформах x86/x64 частью процесса начальной загрузки является считывание загрузочного сектора с диска и загрузка его в таблицу FAT, которая, в свою очередь, должна быть загружена в достаточно высокие адреса памяти, чтобы гарантировать, что последующая загрузка в память freeldr не перезапишет таблицу. К сожалению, версия freeldr, скомпилированная при помощи MSVC, имеет больший размер, чем версия, полученная с использованием GCC, что приводило к перезаписи таблицы FAT и проблемам в работе загрузчика. Когда загрузчик пытался запросить таблицу FAT, чтобы определить, нужно ли загрузить ещё что-то, он получал код freeldr вместо данных и предполагал, что необходимо продолжить работу. Однако попытка использовать код freeldr в качестве информации о необходимых для загрузки данных приводила к сбою работы загрузчика и выдаче ошибки, поскольку загрузчик полагал, что загрузка freeldr также завершилась неудачно. Это было не так, ведь сам freeldr фактически уже завершил загрузку. Тимо устранил эту проблему, изменив адреса, куда загружается таблица FAT, что позволило избежать перезаписи таблицы программным кодом, скомпилированным в MSVC.

Другая проблема, также связанная с файловой системой, была обнаружена в драйвере файловой системы именованных каналов (npfs). Драйвер поддерживает связанный список клиентских блоков управления (Client Control Blocks, CCB), а доступ к этому списку синхронизируется при помощи блокировки. Однако имелся способ получить доступ к 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, было связано с завершением работы соединений. У соединений TCP имеется протокол синхронизации, включающий в себя пакет FIN, который указывает, что передача данных завершена. При вызове функции shutdown(SD_SEND); должен генерироваться пакет FIN, но соединение должно оставаться открытым для чтения. К сожалению, библиотека oskittcp не делала этого и полностью закрывала сокет, что могло привести к провалу любые попытки чтения, произведённые после вызова функции завершения работы соединения. Конечно же, код ReactOS выявлял эту ошибку, полностью завершая работу сокета, когда операция чтения возвращала нулевые байты. Это предотвращало дальнейшие попытки передать данные через это соединение после окончания операции чтения. Последняя проблема, которую устранил Камерон, также происходила из-за oskittcp, поскольку библиотека не оповещала ОС о сбоях соединения. После устранения этой проблемы сетевой стек ReactOS проходит значительно большее количество тестов, и, как мы надеемся, гораздо более пригоден для использования. Одновременно, проблемы в oskittcp подталкивают нас к переходу на библиотеку lwip.