ROS Newsletter77

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

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

0.3.12

Вы наверняка уже заметили на главной странице сайта выпуск ReactOS версии 0.3.12. Во многих отношениях этот выпуск является скорее промежуточным этапом развития ReactOS, чем перенасыщенным новыми возможностями и функциональностью. Те 10 месяцев, что прошли с момента выпуска версии 0.3.11, стали самым длинным циклом разработки, в течение которого разработчики могли бы добавить новые возможности. Глубокие изменения в основных модулях системы, к сожалению, привели к многочисленным регрессиям, но именно отсутствие регрессий было непременным условием для текущей версии. По этой причине, только наиболее важные из них были включены в версию 0.3.12, другие должны быть добавлены в будущем. Самым большим таким модулем стал новый менеджер памяти, который будет подробно описан в следующем разделе.

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

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

Альтернативный модуль диспетчера памяти ReactOS (ARM3)

Переписывание диспетчера памяти, о котором упоминалось ранее, было начато командой ARM, и им, во многих отношениях, удалось добиться очень хороших результатов. Внесение изменений в столь важный компонент операционной системы — крайне нелёгкая задача; хуже того, появление регрессий, ошибок и множества других проблем было практически неизбежно, вне зависимости от того, какой подход команда ARM использовала при переписывании. Тем не менее, чтобы свести к минимуму негативные последствия изменений в этом модуле, команда ARM решила постепенно замещать существующие алгоритмы и функции имеющегося диспетчера памяти новым кодом. На начальном этапе команда сосредоточилась исключительно на создании правильных структур данных, необходимые для отслеживания использования памяти и отображения виртуальной памяти в адресное пространство физической памяти. Затем, модуль ARM3 принял на себя распределение конкретных типов памяти, таких например, как пул памяти ядра. В 0.3.12 новый диспетчер памяти способен производить все распределения пула памяти, но даже эта функция была отключена из-за риска регрессий. На момент выхода версии 0.3.12, команда ARM добавила исправления для всех проблем, которые им были известны, и заставила ARM3 взять на себя не только распределение памяти пула, но и инициализацию диспетчера памяти в ранней стадии загрузки системы. Проект с нетерпением ожидает замены текущего диспетчера памяти на ARM3, это не должно занять много времени.

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

CMake

Усилия по переходу на CMake начинают давать первые результаты, и с его помощью уже можно создать работающий загрузочный диск LiveCD. Неудивительно, что в процессе преобразования были обнаружены ошибки, хотя я сомневаюсь, что кто-либо из разработчиков ожидал увидеть настолько безрассудную ошибку, как та, которую Амин Хальди и команда ARM обнаружили в коде поддержки объявления экспорта в библиотеках. RBuild, по-видимому, позволял экспортировать отсутствующие в DLL функции, что могло привести к достаточно фатальным последствиям, если бы кто-либо попытался использовать их. Более того, RBuild не генерирует и не связывает правильно объявленные функции. При этом создаются несуществующие в DLL функции, поскольку объявления экспорта, создаваемые для этих функций, не совпадают с самими функциями. Удивительно, но успешная сборка ReactOS в RBuild при неправильном экспортировании функций была лишь побочным эффектом плохой обработки объявления функций. В сочетании с другой особенностью RBuild, когда при отсутствии соответствующей функции DLL связывалась сама с собой, это приводило к нарушению структуры самой библиотеки. Первоначально такие проблемы были обнаружены в библиотеке kernel32, которая работала при множественных ошибках семантики и при этом не беспокоила своих пользователей, что само по себе является маленьким чудом. Существует особый случай для функций, экспортируемых библиотекой DLL, но на самом деле импортируемых из другой библиотеки, если вам интересно, что происходит в этом случае, то вы можете почитать об этом самостоятельно. Суть заключается в том, что kernel32 экспортировала несколько несуществующих функций и связывалась сама с собой; эти проблемы были успешно исправлены и в транке, и в ветви CMake. К счастью, ни одна из описанных выше проблем не повлияла на переход на CMake, и, надеюсь, не повлияет в будущем.