ROS Newsletter96

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

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

Тестирование и отладка

Несомненно, самым сложным моментом при написании любого программного обеспечения является поиск источника ошибок. Именно поэтому хорошие тестеры очень важны, а те тестеры, которые умеют пользоваться инструментарием для отладки, важны вдвойне. Совсем недавно нам удалось обнаружить и устранить две ошибки, которые нашел один тестер - Олаф Сейка (Olaf Siejka).

Первая проблема была связана с Microsoft Excel Viewer, как нетрудно догадаться по его названию, это приложение предназначено для просмотра (но не редактирования) файлов Microsoft Excel. Word Viewer уже довольно неплохо работает в ReactOS, а вот проблема с Excel Viewer привлекла внимание Олафа. Воспользовавшись OllyDbg, который, по мнению Олафа, является наиболее дружелюбным к пользователю и удобным в работе отдладчиком из всех, которыми ему приходилось пользоваться, он смог отыскать источник возникновения ошибки, а затем сравнил параметры, значения регистров и возвращаемые проблемной функцией значения. Проанализировав всё это, с небольшой помощью Янниса Адамопулоса (Giannis Adamopoulos) и Томаса Фабера (Thomas Faber), он смог определить, что в процессе отрисовки изображения передавался хэндл со значением NULL. Приложение Excel Viewer обнаруживало эту проблему и аварийно завершало свою работу, и это, несомненно, очень хорошо, поскольку в этом случае какое-либо другое приложение просто попыталось бы продолжить работу, что привело бы к его критическому сбою. Олаф передал все свои наработки Томасу, которому удалось определить, что ReactOS неправильно предоставлял сведения о поддержке некоторых операций. Тимо Кройцер занялся решением этой проблемы, и опрашивая графическое устройство, а затем проверяя правильность ответов о поддерживаемых операциях, смог заставить Excel Viewer запуститься и корректно работать.

Вторая проблема была куда более сложной, и фактически состояла из двух проблем, одна из которых уже исправлена, а работа над поиском и исправлением второй пока ещё ведётся. Эти ошибки проявлялись в сбое работы программы установки пакета OpenOffice, и о существовании этой проблемы известно уже более двух лет. Олафу удалось найти ревизию, в которой появилась регрессия. Поскольку ревизия была довольно старой, ему пришлось изрядно повозиться с несколькими различными средами сборки, чтобы собрать образ диска для тестирования. В проблемной ревизии был добавлен код, над которым работал Пьер Швейцер (Pierre Schweitzer) в рамках разработки библиотеки времени выполнения файловой системы (FsRtl), однако после тщательного анализа кода Пьеру так и не удалось обнаружить ничего подозрительного. Кроме того, автоматическое тестирование также не выявило каких-либо проблем с кодом Пьера. С помощью Янниса, Олафу удалось обнаружить, что сбой в работе программы установки происходил при попытке распаковки файлов с именами с f0_001 по f0_088. Сама программа установки находит эти файлы при помощи шаблона из подстановочных знаков. Яннис проследил всю цепочку вызовов функций от программы установки OpenOffice до FsRtl в Windows, что позволило получить образец правильного поведения системы во время работы этого приложения.

В то же самое время к работе над устранением этой ошибки подключился Виктор Мартинес (Victor Martinez) и занялся созданием тестов для FsRtl. При помощи этих тестов, Олаф проверил несколько различных комбинаций шаблонов имён файлов и обнаружил, что ReactOS не может найти те файлы, которые должна находить при обработке шаблона. Пытаясь понять причину проблемы, Олаф начал последовательно сравнивать строки путей, передаваемых в стеке файловой системы в Windows. Свою работу он начал в режиме пользователя и воспользовался утилитой ApiMonitor, которая позволяет отображать параметры, передаваемые функциям, а также возвращаемые этими функциями значения.

В ходе работ по поиску проблемы было обнаружено, что ошибки при обработке подстановочных знаков происходят как в FsRtl, так и в kernel32. Оказалось, что в FsRtl имеются проблемы при работе с не-юникодовыми путями, а kernel32 неправильно преобразует подстановочные знаки в не-юникодовые. На данный момент с исправленными версиями этих библиотек программа установки OpenOffice уже может отыскать файлы, которые ей необходимо распаковать, однако появилась другая проблема. С момента обнаружения первой ошибки уже прошло некоторое время, и Алексей Брагин добавил в кодовую базу проекта результаты своей работы по полному переписыванию кода загрузчика динамических библиотек, попутно внеся в систему регрессию, препятствующую успешному завершению работы программы установки. И хотя работы над поиском и исправлением этой проблемы всё ещё не завершены, на данный момент уже можно с гордостью сказать, что при устанении ошибки в FsRtl было решено множество проблем и был устранён целый класс ошибок в коде различных компонентов операционной системы.

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

Отладчик ядра

Для повышения удобства разработки системы и облегчения процесса поиска ошибок в режиме ядра, проектом был создан отладчик ядра ReactOS, работающий с системой, собранной при помощи пакета GCC. У Microsoft имеется схожая система, предназначенная для отладки Windows, являющаяся частью довольно обширной экосистемы, содержащей большое количество инструментов для облегчения отладки системы. Однако проблемой является то, что отладочные интерфейсы, используемые в этих двух системах, не совместимы между собой. Чтобы разработчики ReactOS могли воспользоваться всеми преимуществами экосистемы от Microsoft, Алекс Ионеску (Alex Ionescu) проделал немалую работу по добавлению в ReactOS поддержки отладчиков от Microsoft, однако эта поддержка работоспособна лишь в том случае, если ReactOS собрана при помощи MSVC. Эрмес Белуска-Маито (Hermes Belusca-Maito) продолжил его работу и попытался узнать, возможно ли изменить архитектуру имеющегося отладочного интерфейса ReactOS таким образом, чтобы она полностью соответствовала имеющейся в Windows. Хотя функциональность обоих интерфейсов отладки ядра довольно схожа, в них всё-таки имеются некоторые довольно значимые различия. Например, отладочный интерфейс ReactOS работает лишь с отладочными символами GCC и не может использовать символы, генерируемые компиляторами от Microsoft, зато предоставляет возможность отлаживать систему на том же компьютере, на котором она запущена, что может быть очень полезно в некоторых ситуациях. В итоге работ над усовершенствованием механизмов отладки системы проекту хотелось бы получить единый универсальный отладочный механизм, функционирующий как в сборках GCC, так и в сборках MSVC. Эрмесу для этого предстоит ещё сделать очень многое, но прежде всего необходимо внести изменения в сам отладочный интерфейс ReactOS для более точного соответствия интерфейсу, используемому в операционных системах Windows.

Управление темами оформления

Рудиментарная поддержка тем оформления в ReactOS существует уже некоторое время, однако её использование было осложнено отсутствием инструментов для простой настройки. Одним из таких инструментов является апплет панели управления "Рабочий Стол", вкладки которого не были заполнены. Одна из причин этого была связана с тем, как desk.cpl читал значения из файлов тем, а точнее даже с тем, когда именно он их читал. Ранее, desk.cpl не мог прочитать значения метрик из не применённой темы, что приводило к тому, что для изменения таких параметров, как размер и цвет, пользователь должен был сначала применить тему оформления, а уже потом изменять эти значения. Яннис изменил desk.cpl таким образом, что теперь апплет читает значения из файла темы оформления до того, как она будет применена, что позволяет пользователю сначала настроить тему, а уже потом активировать её. Кроме того, он провёл небольшое исследование и обнаружил в библиотеке uxtheme наличие нескольких недокументированных функций, предназначенных для облегчения считывания параметров темы. Тестирование апплета проводилось в Windows XP, поскольку до того, как станет возможным использовать наработки Янниса, необходимо дополнительно поработать и над другими компонентами системы.

Mono

Существует немало приложений, написанных с использованием платформы .NET, особенно в корпоративном секторе. Именно поэтому поддержка этой платформы имеет для нас важное значение со стратегической точки зрения.

Сильвейн Петреоль (Sylvain Petreolle) недавно обратил внимание на проблемы, возникающие при установке пакета Mono, предоставляемого проектом Wine. Сбой программы установки происходил сразу после её запуска, и Сильвейну удалось выяснить, что проблема находится в системном приложении rundll32 в ReactOS. То, что логика работы rundll32 в ReactOS отличается от логики работы rundll32 в Windows стало полной неожиданностью: оказалось, что rundll32 в Windows всегда возвращает 0. Поскольку rundll32 применяется для выполнения функций внутри dll, результатом работы этого приложения может стать широкое разнообразие типов возвращаемого значения. Для упрощения взаимодействия с rundll32 вместо значения результата вызванной функции оно всегда возвращает 0, особенно это удобно по той причине, что код выхода rundll32 может быть использован для обнаружения сбоя в самом rundll32. Правда, до сих пор остаётся неясным, что именно может вызвать возврат ненулевого значения: тесты, проведённые в Windows 2003, показали, что даже при попытке вызвать функцию из несуществующей библиотеки, всё равно будет возвращён код выхода 0. Сильвейн исправил реализацию rundll32 в ReactOS и успешно протестировал в среде Mono программу "Hello World", написанную для платформы .NET