ROS Newsletter94

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

• Публикация на сайте перевода

Переезд сайта

Как многие могли заметить, недавно проект перешёл на использование нового вебсайта, созданного на основе системы управления содержимым (CMS) Drupal. Работы по переносу были начаты в прошлом году, а главной вехой в них стал отказ от Bugzilla и переход на JIRA в качестве основной системы отслеживания ошибок. Однако переход на использование нового сайта прошёл не так гладко, как бы многим, в том числе и мне, того хотелось. Отчасти в этом есть и моя вина, поскольку я отправил email, в котором было сказано, что информационное наполнение сайта находится на достаточно хорошем уровне и позволяет начать работы по переходу на постоянное использование нового сайта. Стоит пояснить, что я имел ввиду, что всё статичное наполнение сайта было перенесено и позволяет перейти на новый сайт, однако выпуски новостей и протоколы собраний разработчиков были отчасти перенесены некорректно, а часть из них не была перенесена вовсе. Кроме того переводы также полностью отсутствовали, а сами процедуры перевода ещё не были как следует обговорены. Однако Алексей Брагин воспринял мой email как символ того, что новый сайт полностью готов, и установил его в качестве нового вебсайта проекта на две недели раньше того момента, на который я ориентировался. Всё это привело к безумной спешке при повторном импортировании выпусков новостей, кроме того, срочно пришлось выяснять, какие разрешения доступа необходимо выдать переводчикам, чтобы они могли выполнять свою работу. Также обнаружилось множество других проблем, начиная с ошибок, возникающих при попытках пользователей войти на сайт под своей учётной записью, и заканчивая простоями работы сайта, которые уже были или ещё только будут устранены. Статическое содержимое также требует доработки, по большей части это скриншоты для некоторых утилит, неработающие ссылки и внесение необходимых дополнений в некоторые инструкции. Стоит отметить, что старый сайт всё ещё доступен, так что ничего из его информационного наполнения потеряно не было, и переводчики могут взять оттуда весь необходимый для перевода нового сайта материал, включая выпуски новостей. Однако значительная часть статичного наполнения нового сайта была либо написана с нуля, либо сильно изменена, так что переводчикам необходимо выполнить довольно большой объём работы. Если бы нам было необходимо извлечь из этого перехода урок, то он, пожалуй, заключался бы в том, что перед началом работ по переходу на использование нового сайта всегда необходимо проверять всё трижды. Но будем надеяться, что проект больше не столкнётся с такой задачей в течение ещё многих и многих лет.

Visual Studio

Разработчики проекта уже давно мечтали заниматься разработкой и сборкой ReactOS в среде Visual Studio. Первым важным шагом для достижения этой цели стал переход на CMake и его способность генерировать solution-файлы. Однако в CMake отсутствовала поддержка некоторых функций, необходимых ReactOS, и Амин Хальди (Amine Khaldi) взял на себя работу по проверке всех файлов CMake с целью убедиться, что все флаги сборки и компоновки выставлены правильно, а предварительно обработанный ассемблерный код и файлы ресурсов обрабатываются корректно. Всё это привело к появлению возможности сборки установочного диска, который смог загрузиться и отобразить работающую пользовательскую оболочку, и даже позволил отлаживать компоненты пользовательского режима с использованием Visual Studio. На данный момент пока ещё имеется несколько компонентов, написанных на языке C++, которые не могут быть скомпилированы, а попытка решения этой проблемы скорее всего потребует внесения изменений в код. Мы надеемся, что скоро у нас появится возможность удаленно отлаживать ReactOS с использованием программного инструментария от Microsoft.

Зависимости

Еще одним большим достижением Амина, заслуживающим похвалы, стали результаты работ по чистке зависимостей различных компонентов ReactOS. До этого попытки изменить любой заголовочный файл в ReactOS чаще всего приводили к необходимости полной пересборки всего проекта. Так происходило из-за заголовков, косвенно использовавших другие заголовки из-за их включения в них, и приводило к тому, что при компиляции исходных файлов использовалось намного большее количество заголовочных файлов, чем это было действительно необходимо. Мало того, что это делало невозможной инкрементную сборку, это ещё приводило и к увеличению нагрузки на компьютер из-за необходимости чтения большого количества файлов с диска и загрузки их в память, что выливалось в общее замедление процесса сборки. Амин вручную проверял различные компоненты, разбирал по отдельности каждый заголовок и оставлял лишь те, от которых действительно зависел конкретный компонент. В результате этого мы получили значительное ускорение сборки, во время которой используется меньшее количество памяти и производится меньшее число операций ввода/вывода на диск, а также возможность совершать инкрементные сборки вместо того, чтобы каждый раз пересобирать всю систему полностью. Произведённая чистка также должна упростить Visual Studio работу по построению его базы данных IntelliSense.

Режимы загрузки

Эрмес Белуска Маито (Hermès Bélusca-Maïto) занимался проверкой правильности загрузки системы в различных режимах безопасной загрузки, поддерживаемых ReactOS. Большинство пользователей, у которых хотя бы раз происходил критический сбой или аварийная перезагрузка системы, должны помнить появляющееся при загрузке системы меню, в котором Windows спрашивает у пользователя разрешения на загрузку компьютера в безопасном режиме из-за неправильного завершения работы системы. Выбор необходимой функциональности загружаемой системы зависит от параметров, передаваемых ядру загрузчиком. В дополнение к базовому набору вариантов загрузки имеется дополнительное меню, позволяющее пользователю самому выбрать необходимые ему функции. Возможно даже выбрать нужный набор параметров, выйти и вернуться в это меню вновь, если пользователь по какой-либо причине решит вновь поменять какие-либо параметры. Однако в ReactOS выбранные параметры просто дописывались в строку, которая в дальнейшем будет передана ядру в качестве параметров загрузки. При возврате назад для выбора другого параметра ранее сформированная строка могла быть не перезаписана, что означало, что ядру могло быть передано большое количество параметров загрузки, из которого обрабатывался только первый набор. Эрмес изменил способ сохранения загрузчиком выбранных параметров на такой, при котором строка с параметрами формируется лишь тогда, когда пользователь окончательно выбрал режим загрузки, что и стало решением этой проблемы.

Последовательный порт VPC

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

CSRSS

Изначально работы по полному переписыванию CSRSS (подсистемы клиент/сервер времени выполнения), представляющей собой сервис пользовательского режима подсистемы Win32, выполнялись Алексом Ионеску (Alex Ionescu). Однако полученный в ходе этих работ код до сих пор используется не полностью, и Эрмес решил посмотреть почему. Прежде всего нужно было внести изменения в различные системные библиотеки, такие например, как kernel32 и ntdll, что позволило бы им корректно работать с новой реализацией CSRSS. Поскольку ранее не существовало инфраструктуры для взаимодействия системных библиотек и CSRSS, то имеющийся на данный момент метод обмена данными между библиотеками DLL и CSRSS не совместим с новой и куда более корректной реализацией CSRSS. Кроме того, Эрмес занят доработкой консоли, которая также является компонентом ReactOS, зависящим от CSRSS. Он столкнулся с невозможностью изменения некоторых параметров консольного окна, например цвета текста и фона, и в результате проведённого им исследования он обнаружил проблему в коде, отвечающем за сохранение в системном реестре и загрузку оттуда настроек конфигурации. Осталось ещё немного доработать различные компоненты системы, и новая реализация CSRSS будет полностью интегрирована в транк.

Рабочие столы

Когда Яннис Адамопулос (Giannis Adamopoulos) узнал что Эрик Коль (Eric Kohl) работает над диалогом блокировки рабочей станции, то обнаружил что код, отвечающий непосредственно за саму блокировку рабочего стола, отсутствует, и реализация этой функциональности не составила ему особого труда. К тому же Яннис достиг значительных успехов в разработке возможности использования нескольких рабочих столов. Этот тип обработки рабочих столов очень далёк от того, к которому привыкли пользователи дистрибутивов Linux. В Windows несколько рабочих столов представляют собой прослойку для безопасности и изолирования и призваны обеспечить правильное разделение многопользовательских окружений. Далее будет необходимо проинформировать CSRSS о наличии нескольких рабочих столов, поскольку на данный момент попытки создания нескольких консолей приводят к тому, что они создаются на рабочем столе по умолчанию, и эта работа потребует общих усилий Янниса и Эрмеса. Хотя нужно проделать ещё довольно много работы, всё то, чего смог достичь Яннис на данный момент, очень впечатляет и заслуживает похвалы сообщества. Современные приложения, которым необходим высокий уровень безопасности, используют объекты рабочих столов для создания изолированных окружений, и для их работы ReactOS необходима правильная реализация рабочего стола.

О публикациях...

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

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