Доступен перевод 92 выпуска новостей проекта ReactOS, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003).

Улучшения в Win32

Глубоко в GDI находится код, предназначенный для обработки ряда растровых операций, в том числе применения шаблонов к растровым изображениям. Для повышения производительности крайне желательно иметь оптимизированные версии этого кода для различной глубины цвета изображений. В действительности же, в ReactOS имелось всего несколько таких версий кода для трёх наиболее часто используемых операций, а остальные операции производились одним и тем же неоптимизированным кодом. Со старым кодом, к тому же было крайне сложно работать и Тимо Кройцер (Timo Kreuzer) предпринял две попытки исправить ситуацию.

Первая попытка закончилась неудачей, однако Рафал Харабиен (Rafał Harabień) смог убедить Тимо в необходимости продолжения этой работы и Тимо удалось создать улучшенный способ генерации оптимизированных функций для всех растровых операций. Тимо разделил все растровые операции на категории исходя их того, какие данные им нужны в качестве входных, выходных и/или шаблонов. Например, для операции инвертирования не требуется шаблон. На основе этих категорий Тимо может удалять неиспользуемый код при генерации функции. Полученный программный код позволяет генерировать около 1200 оптимизированных функций растровых операций.

Ещё одним небольшим, но очень важным изменением, над которым работал Тимо, является переключение большей части подсистемы win32k на использование программных операций с плавающей точкой, возможность которого он добавил в кодовую базу ещё несколько лет назад. Состояние модуля обработки операций с плавающей точкой (FPU) не сохраняется в режиме ядра, поэтому использование FPU в режиме ядра является не самой хорошей идеей. Для решения этой проблемы нужна была лишь оригинальная работа Тимо по добавлению поддержки программной обработки операций с плавающей точкой, однако переход на её использование в большей части кода, например, при координатных преобразованиях, был произведён лишь недавно. Более специализированные функции прорисовки, такие, как построение дуг, до сих пор используют FPU.

Исключения, прерывания и ловушки

Некоторое время назад команда ARM переписала значительную часть кода поддержки низкоуровневых операций с ассемблера на язык C. Необходимость этого переписывания была вызвана желанием сделать этот код более гибким и читаемым, что, разумеется, очень хорошо, однако, к сожалению, в созданный ими код вкралось несколько ошибок и неточностей. Наверное самой раздражающей из них для некоторых тестеровщиков была ошибка, выражавшаяся в невозможности останова системы и входа в отладчик при присоединённом WinDBG во время отладки ReactOS. Одной из куда более серьёзных проблем была ошибка, из-за которой модуль обработки операций с плавающей точкой отключал прерывания, а после завершения своей работы не включал их вновь. И всё это лишь малая часть ошибок, которые устранил Стефан Гинсберг (Stefan Ginsberg) после возвращения в проект.

Вероятно, самым большим хаком, удалённым Стефаном, стал код, допускавший повреждение страниц памяти при запрещённых прерываниях. Этого не должно происходить, так как при обращении диспетчера памяти к сохранённым на диск страницам памяти, он должен использовать стек драйверов устройств, использующий прерывания практически для всех операций. Этот хак был удалён после того, как Стефан при помощи Тимо обнаружил основную причину повреждений. Фактически, код обработчика ловушек, вызывавший повреждения страниц, не разрешал прерывания до завершения своей работы за исключением случаев, когда прерывания были запрещены ещё до начала работы кода обработчика ловушек.

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

Однако в системе всё ещё осталось несколько проблем разной степени важности. В ReactOS в рудиментарном виде имеется поддержка мультипроцессорных систем, которая хоть и не позволяет полноценно использовать все возможности многопроцессорных или многоядерных систем, однако даёт возможность запускать операционную систему на такой платформе, используя лишь один процессор/ядро. Похоже что в этом коде, после перехода с ассемблера на использование C, также содержится ошибка, хотя Стефан никак не может её обнаружить. Куда гораздо более серьёзной проблемой является то, что ReactOS портит содержимое стека при пошаговом выполнении инструкций во время отладки. Эта проблема, как полагает Стефан, возникла при переписывании кода поддержки ловушек, хотя точно в этом он не уверен.

Прощание с Pageop

Несколько лет назад состоялся разговор с Артом Йерксом (Art Yerkes) о состоянии и проблемах диспетчера памяти ReactOS. Одной из самых крупных архитектурных проблем было использование операций под названием pageop, представлявших собой довольно необычную попытку разрешения конфликтов при одновременном доступе к элементу таблицы страниц. Когда диспетчер памяти принимает решение о необходимости сохранения страницы на диск, всегда существует возможность того, что этот процесс может быть прерван или другой поток может предпринять попытку изменить состояние или содержимое этой страницы. В этом случае, если доступ не синхронизирован, это действие может привести к повреждению данных.

Операции pageop были предназначены именно для исключения вероятности повреждения данных, для чего они следили за состоянием обработчика ошибок. Для хранения состояния pageop могло потребоваться выделение дополнительной памяти, что привело бы к проблемам в том случае, если диспетчер памяти попытается выгрузить страницы на диск, чтобы освободить память. Проведя довольно большую и сложную работу, а также выслушав предложения от Алекса Ионеску (Alex Ionescu) и Трэвиса Гейзельбрехта (Travis Geiselbrecht) из NewOS, Арт наконец нашёл более простой и практичный способ синхронизации одновременного доступа при операциях с элементами таблиц страниц.

Инструментарий для сборки

Одной из жалоб, появившихся после перехода на использование CMake, является медленная, по сравнению с RBuild, сборка системы. Частично эту медлительность можно списать на то, что CMake гораздо лучше проверяет зависимости, чем RBuild, что, несомненно, очень и очень хорошо. Чтобы хоть немного смягчить эту проблему, была начата работа, включающая в себя улучшение поддержки предварительно откомпилированных заголовков в самом CMake, а также переход на новую систему сборки под названием ninja.

Система ninja была создана разработчиком Chromium Эваном Мартином (Evan Martin) для обеспечения возможности как можно более быстрой сборки. Сборочные файлы ninja изначально созданы таким образом, что могут быть сгенерированы системой высокого уровня, такой, например, как CMake, а это как раз то, что нужно проекту ReactOS. Амин Хальди (Amine Khaldi) знаком с ninja уже в течение некоторого времени, и работал над возможностью сборки ReactOS с помощью этой системы. Поскольку ninja ещё очень молодой проект, в нем имеется достаточно много отсутствующих функций. На данный момент самым большим недостатком является отсутствие поддержки зависимостей MSVC, которая в ninja находится в стадии разработки. До настоящего времени проект ReactOS успешно сотрудничал с множеством различных сторонних проектов и Амин считает, что спустя некоторое время ReactOS сможет совершить переход на использование ninja.

Сейчас, пожалуй, стоит вкратце напомнить о том, чем различаются система сборки (например, ninja) и среда сборки (например, CMake). В файлах ninja содержатся команды для компиляторов и компоновщиков, позволяющие полностью собрать программу, в то время, как CMake генерирует файлы для сборки, которые могут представлять собой или make-файлы или файлы для ninja. Оба этих компонента дополняют друг друга и не имеют прямых аналогов.

IPv6

Мир плавно движется в направлении IPv6, и хотя сама ReactOS в ближайшее время вряд ли будет к этому готова, однако инфраструктура проекта может быть довольно быстро переведена на использование этого нового протокола. Пьер Швейцер закончил настройку различных серверов и систем, на которых функционируют веб-платформа и основные IT-службы проекта, что позволит инфраструктуре быть доступной по IPv6 в ходе подготовки к дню запуска IPv6, который состоится 6 июня, а до тех пор будет проводиться тщательное тестирование.