ROS Newsletter98

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

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

Проводник

Недавно проект объявлял о заключении контракта с Яннисом Адамопулосом (Giannis Adamopoulos) на разработку компонентов системы, необходимых для запуска и корректной работы в ReactOS оболочки explorer-new. Яннис немедленно приступил к работе и смог добиться значительного прогресса в своей работе, значительная часть которой заключалась в правильном распределении обязанностей между различными компонентами оболочки таким образом, чтобы можно было легко понять назначение каждого из них.

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

Другим крупным достижением Янниса является доработка трёх классов оболочки – IShellBrowser, IShellView, и IShellFolder. Все эти классы работают совместно и предназначены для отображения Рабочего стола и Проводника в том виде, в котором мы все к ним привыкли. IShellBrowser и его потомки отвечают за окна, с которыми работают пользователи, включая меню и панели инструментов, IShellView предназначен для поддержки отображения файлов и папок в виде файлов и папок, по которым пользователь может щёлкнуть мышкой, а IShellFolder предоставляет IShellView информацию о том, какие файлы и папки необходимо вывести на экран. По счастью весь процесс взаимодействия между ними довольно неплохо задокументирован, так что Яннис знает, что делает.

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

Тем не менее предстоит ещё немало работы, в том числе и по доработке поддержки меню Пуск. Классы, предназначенные для поддержки меню Пуск, не документированы, и Яннис, а также Томас Фабер (Thomas Faber), провели небольшое исследование с целью попытаться понять внутреннее устройство и принцип взаимодействия компонентов меню Пуск. Предстоит также ещё поработать и над панелью, к которой прикрепляются панели инструментов, и по которой пользователь может их перемещать. Всего этого, вкупе с другими успехами Янниса в работе над контрактом, теоретически должно быть достаточно для запуска и нормальной работы нового Проводника.

В заключение можно добавить, что Яннис в своей работе успешно смог воспользоваться большим количеством кода, написанным Эндрю Хиллом (Andrew Hill), бывшим разработчиком ReactOS, который в своё время сделал первые шаги в сторону разработки правильной реализации shell32. И, хотя Эндрю более не является участником нашего проекта, его работа доказала свою ценность и проект безмерно ему благодарен за проявленное им при разработке усердие. Ещё одним человеком, чей код оказался крайне полезен в работе Янниса, является Колин Финк (Colin Finck). Изначально работа Колина представляла собой попытку реализации Консоли управления Microsoft (Microsoft Management Console), но Яннис использовал её в качестве отправной точки во время работы над поддержкой панелей инструментов.

Блок управления отображением

Для того, чтобы ReactOS могла поддерживать более сложные файловые системы, нежели FAT, необходима доработка её инфраструктуры поддержки файловых систем. Один из необходимых наборов runtime-библиотек файловой системы помимо всего прочего включает в себя блок управления отображением, предназначенный для поддержки отображения между виртуальными и логическими блоками. Проще говоря логические блоки представляют собой то, как данные физически располагаются на диске, а виртуальные блоки являются абстракцией, представляемой операционной системой. Алексей Брагин разработал реализацию этого блока, а Пьер Швейцер (Pierre Schweitzer) создал набор тестов для её тестирования. Алексей запускал эти тесты в Windows 2003, наблюдал за их работой, и на основе полученных результатов занимался разработкой кода этого компонента. В результате значительная часть тестов для этого компонента завершается успешно, за исключением всего лишь нескольких довольно сложных условий его работы, например при слиянии виртуальных блоков в условиях непрерывных логических блоков. Как только все проблемы в коде будут устранены, в стеке файловых систем появится ещё одна полностью завершённая часть.

Улучшения в процессе сборки

Хотя Амину Хальди (Amine Khaldi) и удалось в ходе работ по переходу на ninja добиться уменьшения количества времени, необходимого для сборки системы, однако он всё равно остался не полностью удовлетворён полученными результатами и внёс в процесс сборки ReactOS ещё четыре изменения. Первое крупное изменение коснулось уменьшения количества отладочной информации, создаваемого для использования совместно с rossym. Ранее rossym работал с отладочной информацией в формате stabs, однако этот формат не позволял задавать уровень детализации выдаваемых данных. Арт Йеркс (Art Yerkes) позаимствовал код из компонента dbghelp, разработанного проектом Wine, что позволило встроить в rossym поддержку отладочной информации в формате DWARF, и Амин получил возможность настроить процесс сборки таким образом, что при сборке системы генерируется лишь абсолютный минимум необходимой rossym отладочной информации. Ещё одно улучшение представляет собой изменения в процессе формирования образов дисков. Амин изучил процесс компоновки файлов ISO и предоставил Арту свои соображения по внесению в него изменений. Арт модифицировал утилиту cdmake таким образом, что она теперь может читать файл с описанием расположения компонентов образа диска, и системе сборки более не придётся каждый раз создавать директорию и дублировать в ней двоичные файлы для сборки.

Два других изменения были нацелены на уменьшение времени сборки. Одно из этих изменений заключалось в использовании чуть менее эффективных параметров создания файлов cab, что позволило уменьшить время сжатия архива на 50% ценой увеличения объёма получаемого архивного файла всего лишь примерно на 65 кб. Другое изменение коснулось изменения уровня оптимизации, применяемого при компиляции ReactOS, а именно O1 вместо Os. Параметр Os отвечает за оптимизацию размера и при этом пытается оптимизировать результат так же, как и O2, в то время, как O1 не настолько агрессивен с точки зрения оптимизации. Проведя небольшое исследование, Амин обнаружил, что O1 практически не ухудшает производительность, если сравнивать его с Os, однако процесс компиляции идёт быстрее из-за менее агрессивной фазы оптимизации. Кульминацией всего этого стало уменьшение с 4 Гб до примерно 500 Мб места на диске, занимаемого при компиляции ReactOS, кроме того, уменьшение размера используемого дискового пространства означает уменьшение количества операций ввода/вывода во время процесса сборки, а также возможность кэшировать всю сборку непосредственно в оперативной памяти, что позволяет ещё больше ускорить процесс сборки, а также означает то, что на серверах проекта будет свободно большее количество оперативной памяти, и они смогут заниматься одновременной сборкой нескольких ревизий или же другой полезной работой. За это значительное достижение Амину и Арту благодарны все разработчики проекта, ведь им теперь не придётся подолгу дожидаться окончания процесса сборки.