ROS Newsletter55

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

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

Шрифтовой движок

Существует разница между правильностью функционала и правильностью реализации, и ее всегда надо иметь в виду, когда говоришь, что что-то работает в ReactOS. В случае с отрисовкой текста, внутренняя реализация не имеет вообще ничего общего с тем, какой она должна быть. Цепочка вызовов функций для отображения текста - это TextOutA/W, NtGdiExtTextOutW и GreExtTextOutW. Существуют несколько вариаций, но вышеназванный способ показывает общую идею того, как поток управления спускается до уровня функции GRE. В ReactOS этой функции вообще нет, и модуль Win32K просто вызывал NtGdiExtTextOutW. Поскольку эта функция является системным вызовом, взаимодействует с пользовательской памятью и, следовательно, должна проверять передаваемый буфер на принадлежность к ней, вызов этой функции в режиме ядра с буферами памяти ядра вообще не должен сработать. Оно работало из-за одной ошибки в функции MmCopyFromCaller, которая копирует данные из пользовательских буферов в буферы ядра. Ожидалось, что она будет проверять буфер назначения на то, является ли он пользовательским, однако проверка не работала, поэтому Win32K успешно использовала NtGdiExtTextOutW. Кроме всего прочего, функция MmCopyFromCaller вообще не должна существовать. Это заплатка, существующая только в ReactOS, и функция NtGdiExtTextOutW должна использовать SEH для проверки получаемого буфера. Причиной, по которой Win32K должна использовать GreExtTextOutW, является тот факт, что Win32K работает с буферами ядра, а GreExtTextOutW требует такой буфер для своей работы, следовательно можно автоматически доверять любому передаваемому буферу без проверок. Это широко распространенная практика среди функций, которые должны работать только в том случае, если они вызваны в режиме ядра.

Кроме того, ReactOS также не использовала структуры данных STROBJ / ESTROBJ, применяемые для описания набора символов и их положений - по сути, текста, который требуется вывести. Функция GreExtTextOutW вызывает ESTROBJ::vInit для инициализации структуры, также передавая данные, согласно которым ее можно заполнить и провести необходимые преобразования координат. Функция ESTROBJ::vInit также проверяет структуру RFONTOBJ, хранящую информацию о глифах шрифта. Когда эта операция завершена, структура STROBJ передается в функции EngTextOut или DrvTextOut. Префикс Eng указывает на то, что это встроенная функция отображения, которая применяется в том случае, если конкретный видеодрайвер не предоставляет требуемого функционала. Проблема в ROS заключается в том, что ни одна из этих структур данных не существуют, следовательно вся цепочка отрисовки также не выполняется. Более того, в ReactOS Win32K не существует реализации EngTextOut, а функция DrvTextOut попросту игнорируется, даже если она и существует.

Тимо Крейцер (Timo Kreuzer) работает над исправлением данной ситуации, и на драйвер шрифтов он потратил достаточно много времени. Вышеупомянутая структура данных RFONTOBJ также используется в качестве кеша для хранения глифов, уже однажды отрисованных. Однако если глиф требуется отрисовать впервые, вызывается драйвер шрифта, связанный со структурой RFONTOBJ. В этом драйвере шрифта существует функция DrvQueryFontData, которая собственно отрисовывает глиф и возвращает либо массив битов (bitmap), либо абрис (outline). Следующим шагом будет реализация самих структур RFONTOBJ и STROBJ с последующим переписыванием отрисовывающих текст функций так, чтобы эти структуры использовались. На это Тимо потребуется еще год, или около того.

Объяснив все, что ReactOS пока не умеет делать, было бы неправильно хотя бы не показать примерно, что она умеет, не важно насколько хорошо. Вместо того, чтобы обращаться к драйверу шрифтов за информацией о глифах, все это пропускается и библиотека функций Freetype DLL вызывается напрямую. Поскольку функции EngTextOut и DrvTextOut не используются при отрисовке текста, GreExtTextOut просто вызывает Freetype для отрисовки глифов, а потом отображает их с помощью EngBitBlt или DrvBitBlt. Это еще один пример того, насколько все замысловато устроено в ReactOS Win32K.

Сеть

Как уже упоминалось в предыдущем выпуске, Камерон Гутман (Cameron Gutman) продолжил работу над сетевым стеком после того, как Арт Еркс (Art Yerkes) закончил первоначальную реализацию. В основном он исправлял ошибки, например отмену IRP, из-за которой операция ping вызывала зависание. Большая часть этой работы была встроена в версии 0.3.6 и 0.3.7 и распространена на многие компоненты сетевого стека. В частности, ресурсы теперь правильно выделяются и освобождаются, и кроме того возвращаются правильные коды статуса при успешном завершении операции.

Twitter

Гед Мерфи недавно создал и настроил публичный групповой аккаунт Twitter, где заинтересованные разработчики могут сообщать об обновлениях в проекте. Эти обновления будут разосланы обычным твитным методом и получены всеми, кто следит за аккаунтом. Каждый, кто зарегистрируется в качестве следящего за reactos, автоматически будет отслеживаться аккаунтом reactos. Это значит, что эти люди автоматически получат возможность участвовать в групповых твитах, которые будут распространяться по всем следящим. Чтобы послать групповой твит, нужно просто послать прямое сообщение в reactos, в отличие от @reply, и GroupTweet позаботится об остальном. Возможные применения [этой фичи] в будущем включают в себя сообщения об обновлениях во время конвенций.