News #48: Обзор года

2009-01-24, Aleksey Bragin
Обзор года
translated by Shashkov Maxim on 2009-01-27
Оглядываясь на 2008 год

Обзор года

2008 год увидел четыре релиза ReactOS, и все они были представлены после завершения переписывания ядра. Таким образом, нестабильное поведение системы, наблюдаемое в версии 0.3.1, было сведено к минимуму; улучшена работа не только в виртуальных машинах, но и на реальном "железе". И хотя это ещё не означает, что система работает надежно, но всё же мы стали к этому ближе. Число релизов, безусловно, выше, чем в предыдущие года, когда развитие проекта тормозилось нестабильностью ядра.

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

Старички и новички

Весьма много людей присоединилось к проекту в качестве разработчиков, хотя многие из них уже давно были в нашем сообществе, плюс один - вернулся в команду после перерыва. Все 10 новичков и один вернувшийся - теперь с нами, и они уже внесли большой вклад в разработку ReactOS. Первые двое пришедших к нам в начале года - Андрей Коротаев и Дмитрий Чапышев. Затем к нам вернулся Стивен Эдвардс (Steven Edwards), связующее звено с Wine. За ним пришли Маттиас Купфер (Matthias Kupfer), "старичок" сообщества и Джеффри Морлан (Jeffrey Morlan), который открыл для себя проект незадолго до того, как стал одним из разработчиков. После этого присоединился Стефан Гинсберг (Stefan Ginsberg), который сейчас занимает позицию самого молодого разработчика ReactOS и Кэмерон Гутман (Cameron Gutman), другой участник нашего форума, который перешёл в IRC, чтобы общаться с разработчиками напрямую. В то же время Самуэль Серафион (Samuel Serapion), номинально - второй автор выпусков новостей, также получил доступ к репозиторию. Последней тройкой стали Майкл Мартин (Michael Martin), Грегор Шнайдер (Gregor Schneider) и Камил Горничек (Kamil Hornicek), присоединившиеся к нам с месячным отставанием друг от друга. С возросшей численностью разработчиков, будущее ReactOS безусловно выглядит многообещающе.

Графика

Поскольку ядро несколько стабилизировалось, наше внимание переместилось на графическую подсистему. Код этой подсистемы довольно старый и содержит множество хаков, но его исправление - ключ к успешному запуску большего числа приложений. По той же причине несколько разработчиков начали переписывать подсистему Win32, что весьма важно. Основная цель - навести порядок в реализации, внутренней архитектуре и структурах данных, некоторые из которых просто не существуют в реализации Windows. Последнее не допустимо, если мы хотим достичь полной совместимости с Windows, поэтому Тимо Крейцер (Timo Kreuzer) уже начал исправлять ошибки реализации. Некоторые структуры данных являются, на самом деле, объединением уже существующих или их укрупнением. Тимо уже сумел разделить одну специфичную для ReactOS структуру и заменить использовавший её код правильной реализацией, и таких структур, разбросанных по коду, осталось еще очень много. Полная замена потребует большего времени, особенно если код, зависящий от этих неправильных структур, активно развивался.

Другой внутренней проблемой, которой было уделено много внимания в этом году, является наличие перекрёстных зависимостей в подсистеме Win32. Это произошло из-за того, что разработка подсистемы начиналась раньше, чем была публично доступна информация о ней; разработка велась на основе предположений о том, какие связи должны быть. Это в конечном итоге привело к циклическим зависимостям, когда модули зависят друг от друга вместо того, чтобы находиться в строгой иерархии. Эрик Коль (Eric Kohl) потратил много времени, пытаясь упорядочить зависимости и одним из его успехов стало избавление от использования shell32 во время инициализации CSRSS, так как этот компонент даже не был загружен во время запуска CSRSS. К сожалению, это исправление не решает всех проблем с взаимозависимостями, поэтому Джим Табор (Jim Tabor, столкнувшийся с этой проблемой первым) продолжит свой поиск.

Третий вопрос, связанный с архитектурой подсистемы Win32 - реализация ReactX, нашей замены для DirectX. Магнус Олсен (Magnus Olsen) за этот год выяснил, что такая попытка займет гораздо больше времени, чем первоначально предполагалось, особенно из-за поддержки аппаратного ускорения 3D рендеринга. С учётом этого, выбрано два краткосрочных решения. Первое связано с использованием в ReactOS кода Wine, который переводит запросы Direct3D в похожие эквиваленты для OpenGL. Поддержка аппаратного ускорения для OpenGL уже существует, поэтому этот трюк может помочь повысить производительность. Однако, Магнус по-прежнему намеревается сделать надлежащую реализацию, без трансляции запросов в OpenGL. Второе решение заключается в том, чтобы усовершенствовать подсистему Win32 настолько, что официальный DirectX от Microsoft заработает в ReactOS. Это потребует исправления внутренних структур данных, от которых зависит DirectX, и приведения их в вид, идентичный тому, что в Windows. Работа над запуском Microsoft DirectX в ReactOS началась ещё в 2004 году и сейчас появились первые признаки прогресса. Драйвер DirectX загружается и уже работает простой 2D рендеринг с аппаратным ускорением, но до 3D ещё далеко. Данные достижения были получены благодаря работе Магнуса Олсена (Magnus Olsen), Тимо Крейцера (Timo Kreuzer), Джима Табора (Jim Tabor), Мартина Босмы (Maarten Bosma) и Алекса Ионеску (Alex Ionescu), а также присоединившегося к ним недавно Камила Горничека (Kamil Hornicek). Многое, конечно, еще предстоит сделать, но мы сейчас находимся на том этапе, когда прогресс уже виден, и не только внутренний.

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

Файловые системы и память

Работа над этими двумя компонентами шла одновременно, так как драйверы файловых систем очень сильно зависят от служб, предоставляемых MM (диспетчером памяти, Memory Manager). Лишь в 2008 году была начата работа по "латанию дыр", которые мешают использовать отличные от FAT32 файловые системы. Двумя крупнейшими препятствиями являются чрезвычайно неполная FsRtl (библиотека файловой системы) и чрезвычайно некорректная реализация CC (менеджера кеш-памяти, Common Cache).

Проблема с СС известна довольно давно и было несколько попыток его переписать. В действительности, СС - не самостоятельный компонент, его функционал тесно связан с MM. Это означает, что для того, чтобы у нас была правильная реализация СС, необходим хороший MM. Но, к сожалению, это не всё: CC и MM предполагают некоторый уровень абстракции, в нашей же реализации функциональность обоих компонентов перемешана. Первым шагом на пути к их разделению стала NoCС, работа над исключением из функционала СС, которой занимался Алексей Брагин, а затем и Арт Йеркес (Art Yerkes). Алексей занялся этим для того, чтобы мы могли заботиться об исправлении основных операций с памятью (в MM), до того, как будем приводить в порядок функционал CC. Когда мы будем уверены, что MM функционирует правильно, тогда можно пробовать реализовать кеширующие алгоритмы CC. Арту удалось отделить MM от CC, устранив общие структуры данных, каких быть не должно, для начала. Затем он реализовал простой кеширующий алгоритм (LRU, при котором выгружаются на диск самые "старые" страницы) и ReactOS смог загружаться до перехода в графический режим до того, как давать сбой. Учитывая то, что СС практически не существовало на момент начала работы над ним, проделана большая работа, но предстоит ещё большая для завершения в этом году.

Другой компонент, от которого сильно зависят драйверы файловых систем, FsRtl. Большая часть последней пока просто не реализована, так как FAT32 достаточно простая файловая система, позволившая обспечить при помощи хака работу без этого. Пьер Швейцер (Pierre Schweitzer), изначально присоединившийся к команде разработчиков, чтобы помочь со средой сборки ReactOS (RosBE), переключил своё внимание на разработку FsRtl в 2008 году. Он много наработал в отдельной ветке, реализуя как недостающую функциональность в самой FsRtl, так и службы в других компонентах, от которых она зависит. Это ещё одна инициатива, которая требует некоторого времени до завершения, но когда она будет реализована, мы сможем начать более серьёзную работу над поддержкой новых файловых систем.

Портирование

Две затеи были начаты в 2008 году - работы над портированием ReactOS на другие архитектуры, x64 и ARM. Обе они показали значительные результаты, причём портирование на платформу ARM достигло того состояния, когда можно начинать работать над инициализацией компонентов пользовательского режима. Портирование на платформу x64 продвигается медленнее, но также удалось добиться частичной загрузки. При портировании на другие платформы была обнаружена масса ошибок в диспетчере памяти, что также пошло на пользу и ветви x86. Большая часть кода для x64 ещё не перенесена в транк, в то время как работа над ARM ведётся прямо в нём. Тем не менее, проделанная работа предоставляет прочную основу для будущих разработок, а успешное портирование должно открыть новые возможности для ReactOS.

Инфраструктура

В прошлом году было много внимания уделено увеличению производительности разработчиков. Кроме переезда и обновления нашего сервера, начата работа над системой автоматического тестирования для каждой ревизии. Первым шагом в этом направлении стало завершение работы над программой Sysreg Йоханнесом Эндерволдом (Johannes Anderwald) и Кристофом фон Виттичем (Christoph von Wittich). Сейчас она запускается на сервере, предназначенном для сборки, запускает тесты Wine и останавливается при первой ошибке или падении системы. Вообще-то, предполагается, что в дальнейшем Sysreg будет запускать все тесты из модуля Rostests независимо от обнаруженных во время тестирования ошибок. Генерируемые Sysreg отчёты чрезмерно подробны, поэтому Колин Финк (Colin Finck) и другие члены сообщества работают над созданием лучшего веб-интерфейса для Sysreg. Есть надежда, что это даст результаты уже в этом году.

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

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

Сканирование Coverity

Мы стали сотрудничать с Coverity (компанией, занимающейся вопросами анализа исходного кода) благодаря Уриасу Маккалоку (Urias McCullough), члену сообщества Haiku, и представили наш исходный код для анализа. То, что мы стали одним из открытых проектов, с которыми работает Coverity, должно дать большие преимущества в долгосрочной перспективе, помочь нам избежать некоторых типов ошибок, а также обеспечить полную проверку качества.

Компиляторы

Одной из самых больших проблем проекта при использовании нашего основного компилятора GCC, является отсутствие в нём поддержки SEH (Structured Exception Handling - структурная обработка исключений). KJK::Hyperion создал библиотеку PSEH для компенсации этого недостатка и в конце прошедшего года обновил её до версии 2.0. Она всё ещё страдает от нескольких "детских болезней", но уже сейчас делает нас на один шаг ближе к использованию схемы обработки исключений, которая на уровне исходного кода будет одинаковой как для GCC, так и для MSVC (компилятора от Microsoft). Это должно быть очень удобно, так как KJK также работает над возможностью для компиляции ReactOS с помощью MSVC. Результаты этих работ должны помочь нам значительно повысить качество кода.

Финансируемые сообществом идеи

Это предлагалось много раз в прошлом, но не было сделано до середины 2008 года из-за серьезных усилий, необходимых для организации. CFI (Community Funded Ideas - идеи, финансируемые сообществом) предполагают возможность членам сообщества пожертвовать на конкретную функцию из списка, которую они хотели бы видеть завершённой. Преследуемая цель - обеспечение разработчиков необходимыми средствами для того, чтобы они могли уделять время, необходимое для завершения этой функции, без мыслей о своём финансовом положении. Несколько проектов уже получили хорошие суммы пожертвований и мы надеемся, что CFI, в целом, окажутся успешными в будущем. По-прежнему необходимы некоторые усилия в части планирования и организации, но разработчики уже начали предварительные работы по некоторым из предложенных проектов.

News Archive