ROS Newsletter62

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

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

Порча данных в PSEH

В операционных системах семейства NT структурированная обработка исключений (SEH) используется для безопасного освобождения буферов памяти пользовательского режима и страничной памяти в режиме ядра. Это требование мотивировало KJK::Hyperion на создание библиотеки PSEH, так как GCC не имеет поддержки SEH. Так как недавняя попытка добавить её поддержку в GCC провалилась, ReactOS по-прежнему зависит от PSEH. Недавно команда ARM внесла некоторый код, который вызвал очень неприятную ошибку в библиотеке PSEH, и расследование причин подвело KJK к обнаружению ещё одной ошибки в процессе анализа кода. Обе эти ошибки являются серьёзными, так как они оказались причиной крупных проблем при возникновении исключений.

Первая ошибка связана с вложенными блоками try/catch, в которых при возникновении и обработке исключения во внутреннем блоке и возникновении второго исключения во внешнем, управление может передаваться не внешнему блоку catch, а внутреннему. Код продолжит исполняться опять с внутреннего блока, что приведет к бесконечному циклу (из-за непрерывной передачи управления обратно). Проблема была в том, что при выходе из блока значение переменной, отвечающей за уровень вложенности, не загружалось из стека, так и оставаясь в нем, из-за чего PSEH считал, что он по-прежнему во внутреннем блоке. Это, конечно же, делало ОС непригодной для использования, когда происходила ошибка. Так и случилось после внесения кода ARM в репозиторий и автоматического теста, составленного для выявления ошибок. С небольшой помощью Стефана Гинсберга, KJK удалось найти причину этой ошибки с вложенными блоками try/catch, и в настоящее время автоматическое тестирование опять работает.

Вторая ошибка несколько похожа на первую тем, что фрейм стека, в контексте которого выполняется обработка исключения, не удалялся, что приводит к абсолютно непредсказуемым результатам. Настоящая проблема в том, что эта ошибка может активироваться без вложенных блоков try/catch, даже если она не тормозит ОС, то все равно приводит к случайным повреждениям стека, что может повлиять на другие аспекты, и, в итоге, сильно усложняет поиск ошибок. Поскольку это происходило постоянно при возникновении исключения в SEH, нет ничего удивительного в случайных сбоях ReactOS после введения PSEH2.По иронии судьбы, идентичная проблема также существует в PSEH1, и имеет те же причины. Набор тестов PSEH KJK также помог, как только он добавил проверку исправности, которой не было. Конечно, добавление результатов проверки в его код провалило большинство тестов до тех пор, пока он исправит ошибки.

XLATEOBJ

Структура XLATEOBJ используется для преобразования одной палитры в другую, например, из растра в цветовой формат дисплея. Так как эта операция происходит все время, то очень важно, чтобы она была быстрой. В ReactOS своей реализации, к сожалению, не было, одна из его функций, с помощью конструкции if/else принимала решение о том, как делать преобразование. Тимо Kreuzer заменил его вызовом функции, которая выполняется только если необходима оптимизация для специальных форматов. Timo намерен сделать еще одно изменение в XLATEOBJ - вместо динамического выделения из постраничного пула каждый раз когда выполняется операция "bitblt", назначать для нее стек.

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

Arwinss

Алексей Брагин недавно создал новую ветвь под названием Arwinss, которая, кажется, представляет иную реализацию подсистемы Win32 в том или ином виде. Он также разослал подробности по e-mail, почему он сделал это, и чем обосновывается подход. Рассуждения сводятся к тому, что Алексей не удовлетворен текущей подсистемой Win32 и ее многочисленными ошибками. Тогда как некоторые разработчики вынуждены работать долго и много, чтобы получить работающую систему, в ней есть еще крупные, давние ошибки. Многие из них происходят из "хаков" и неправильных реализаций в прошлом, и их устранение, по сути, так или иначе переписывает подсистему. Алексей таким образом решил сделать шаг вперед, повторно переписав всю основу.

Существует значительное количество кода Wine в ветке, импортированного из последнего релиза Wine. Разница в том, что на этот раз архитектура Wine была оставлена без изменений. Иерархия вызовов в Windows может быть удивительно сложна, значительная часть вызовов не продублирована в Wine. Алексей решил продолжать такое упрощение и уплотнять уровни. Он создал значительно меньший компонент Win32k для подсистемы ядра, опять позаимствовав некоторый код Wine, чтобы сделать взаимодействие с пользовательскими библиотеками Wine DLL проще, но внес свои изменения, чтобы всё это работало на NT OS. Эти изменения, вероятно, будут самыми спорными. Сейчас это просто означает, по словам Камила Хорнисека, что использование ветки выглядит как работа с ROS 0.1.0. Текст отображается с полным нарушением границ и мешается в пюре, а цветопередача выдает синюю строку заголовка окна коричневым цветом. Как ожидается, многие вещи будут поставлены на место, но до того, функциональность упадет.

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

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