ROS Newsletter50

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

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

Опасности PSEH2

В связи с тем, что KJK завершил PSEH2 в рекордные сроки, новый код был относительно мало протестирован на тот момент, когда разработчики начали его использовать. Сейчас, похоже, PSEH портит данные во время возникновения исключений, в результате чего вызываемые ниже (по стеку) функции могут не проходить проверку входных данных и аварийно завершаться, от чего PSEH должна была защитить. Майкл Мартин(Michael Martin) предполагает, что это может происходить из-за того, что PSEH портит локальные переменные, находящиеся в регистрах, хотя KJK указывает причиной неиспользование setjmp. Остальные подробности, по его словам, "весьма сложны". KJK внёс исправления для проблемы с порчей локальных переменных, но он ожидает проявления и других проблем. С другой стороны, этот спор о проблеме подтолкнул KJK к написанию набора тестов для SEH. Пока в нём около 70 тестов, которые вскоре будут внесены в транк, со многими другими.

Одна из наиболее серьезных проблем возникает во время входа в систему ReactOS, система фактически не загружает компонент для чтения ввода с клавиатуры. Это предсказуемо приводит к тому, что не удаётся загрузиться дальше входа в систему и к большим разочарованиям со стороны тестеров. К сожалению, даже с самыми последними исправлениями KJK, проблема до сих пор не была полностью решена.

MSVCRT

Библиотека времени выполнения MS Visual С/C++ предоставляет большую часть базовых служб, которые могут требоваться для любой программы, написанной на С/C++, хотя технически MSVCRT была предназначена только для программ, разработанных с помощью Visual C/C++ версий с 4.2 по 6 и для некоторых внутренних компонент. Более новые программы не предполагалось связывать с ней напрямую, хотя для обратной совместимости Windows SDK по-прежнему позволяет это сделать. Что интересно, именно неправильное обращение с MSVCRT в семействе 9x внесло наибольший вклад в обрушившийся на людей DLL Hell (когда различные версии библиотеки не имели между собой совместимости). У ReactOS также есть своя версия MSVCRT, которую создавали с учётом нескольких исходных версий, чтобы удовлетворить различным функциональным требованиям. Это создавало много проблем, с которыми разбирался Грегор Шнейдер(Gregor Schneider), чтобы заставить ROS MSVCRT проходить большее число тестов от Wine. Он далеко продвинулся, практически полностью написав тесты модулей для dir, cpp, printf и string. Большая часть работы заключается в удалении дублирующего и неверного кода и обновлении до версий Wine, реализации которого достаточно стабильны.

Инициализация ядра Win32

Один из самых досадных побочных эффектов, возникающих при решении проблем в ReactOS, заключается в том, что можно обнаружить стоящую за этими проблемами ошибку, которая была "закрыта" хаком в этом месте (исправив который, Вы вынуждены разбираться и с причинами самого хака). Джим Табор (Jim Tabor) наткнулся именно на такую ситуацию, когда решил проблему в GDI32 только для того, чтобы найти ошибку в инициализации подсистемы Win32. Очень многое зависит от ядра Win32, неудачная инициализация которого фактически делает систему бесполезной. Проблема кроется в том, что компоненты инициализируются в неправильной последовательности. Это привело к тому, что разработчики создавали взаимозависимости между некоторыми компонентами, а теперь это вышло нам боком. В данном случае CSRSS пыталась воспользоваться функцией ExtractIconExW, которая расположена в shell32.dll. Проблема в том, что shell32.dll требует достоверного пользовательского аккаунта во время инициализации, в то время как CSRSS фактически является реализацией пользовательского режима для подсистемы Win32. Таким образом, на момент запуска CSRSS пользователь ещё не имел возможности войти в систему. Эрик Коль (Eric Kohl) разбирался со спецификой проблемы, однако Джим уверен, что ей подобные всё ещё скрываются поблизости.

Методология разработки

Как я уже не раз говорил, менеджер памяти (диспетчер памяти, Mm) является, наверно, самым слабым компонентом в ядре на данный момент. Это один из последних участков кода, оставшийся со времён предшествующих переписыванию ядра Алексом Ионеску (Alex Ionescu). Очень хотелось бы исправить его, избежав полного переписывания, которое возможно лишь в долгосрочной перспективе и в данный момент пытаться это сделать просто непрактично. Также следует учитывать, что менеджер кеш-памяти зависит от диспетчера памяти, а файловые системы зависят от менеджера кеш-памяти - и у нас ещё больше причин желать приведения диспетчера памяти в должный вид.

Вместо подхода "снизу вверх", который можно было бы использовать для переписывания кода, Алексей Брагин выбрал путь "сверху вниз" для исправления менеджера памяти. Для того, чтобы сделать это, требуется исправить проблемы в имеющихся драйверах файловых систем, а конкретно - в FastFAT и CDFS. Обе они были разработаны для ReactOS и протестированы затем в NT, в результате чего возникли некоторые проблемы. Вместо этого, Алексей хочет разрабатывать на NT и затем тестировать драйвера в ReactOS, что, вероятно, обнажит всевозможные проблемы менеджеров виртуальной и кеш-памяти, а возможно и FsRtl реализаций вообще. Как и в любом другом подходе, здесь есть свои выгоды. Количество людей, которые хорошо знают, как писать IFS драйвера для Windows исчисляется десятками, как максимум. Как скоро сам Алексей сможет переписать драйвера файловых систем, покажет время.