Доступен перевод 88 выпуска новостей проекта ReactOS, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003).

Shell32

Ещё одним достижением Клаудиу Михаила (Claudiu Mihail), который в рамках недавнего Google Summer of Code преобразовал библиотеку IwIP в драйвер, стало окончание работ по переписыванию библиотеки shell32 с языка C на C++ и интеграция полученного программного кода в транк. Работы по преобразованию были начаты Гедом Мёрфи (Ged Murphy) и Эндрю Хиллом (Andrew Hill), и цель их проведения состояла в том, что C++ наилучшим образом подходит для реализации различных аспектов механизма COM в этой библиотеке. Сначала Гед попытался сконвертировать код непосредственно в транке, однако оказалось, что в этом случае поддерживать целостность кода в транке весьма сложно, и Гед переместил свои наработки в отдельную ветвь. Клаудиу, после завершения своего проекта GSoC, продолжил его работу и доработал код.

Перевод кода с C на C++ нередко выявляет ошибки в коде, такие например, как не заданные значения по умолчанию для элементов класса в конструкторе или некорректно выполненные обновления элементов класса. Одной из самых больших проблем, требовавших исправления, являлось то, что апплеты Панели управления не запускались. Эта проблема возникла после того, как Клаудиу внёс исправления в парсер командной строки для обеспечения прохождения тестов Wine. Парсер корректно уменьшал названия апплетов до их короткой формы, например с "Add Hardware" до "Add", однако из-за проблемы в глубине кода библиотеки, система не могла найти апплеты Панели управления по их коротким именам.

Когда эта проблема была устранена, оказалось, что из-за других ошибок в библиотеке ATL невозможна правильная регистрация расширений в оболочке. Яннис Адамопулос (Giannis Adamopoulos) тоже обращал внимание на проблемы с регистрацией, но так и не смог решить их. Кроме того, Йоханнес Андервальд (Johannes Anderwald) также тщетно пытался справиться с этой проблемой, и заявил, что ATL является неподходящим механизмом для регистрации расширений оболочки. Тем временем Амин Хальди (Amine Khaldi) сделал откат изменений в коде регистрации, что позволило использовать старый механизм регистрации, взятый из Wine и являющийся хоть и архитектурно неправильным, но, по крайней мере, хоть немного работоспособным.

Поскольку корректная реализация shell32 никогда не являлась приоритетной задачей для Wine, то и тестов в наборе winetests для проверки этого компонента очень мало. Клаудиу работает над этим и уже добавил несколько новых тестов для проверки большего количества функций библиотеки. Совместно с Виктором Мартинесом (Victor Martinez) было добавлено несколько тестов для проверки парсера командной строки, а тесты для других составных частей библиотеки, надеемся, скоро также появятся.

Исправления в загрузчике

Прошло уже несколько месяцев с тех пор, как Алексей Брагин добавил в основную кодовую базу результаты своей работы по переписыванию загрузчика, что привело к появлению в системе большого количества регрессий. Однако, как минимум одна из регрессий была связана с маркерами безопасности (security cookies). Они не имеют ничего общего с cookies, используемыми при интернет-сессиях, а предназначены для вызова соответствующих функций для обнаружения повреждений памяти. Повреждения памяти и тому подобные проблемы могут произойти как в стеке, так и в куче. Тем, кто не знает, чем стек отличается от кучи, вкратце можно пояснить, что стеком называется то место, где хранятся все локальные переменные функций, в то время как куча представляет собой источник динамически распределяемой памяти.

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

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

Отладочный пул

Отладочный пул работает схожим с отладочной кучей образом, различия состоят лишь в том, что отладочный пул добавляет дополнительные данные к каждому распределяемому из пула участку памяти, что позволяет отследить компоненты, выходящие за пределы отведённой им памяти. Поскольку обычно повреждение памяти в режиме ядра ведёт к куда более катастрофическим последствиям, в том числе BSoD и другим системным сбоям, своевременное обнаружение и исправление дефектного кода, ответственного за повреждения памяти, становится одной из наиважнейших задач.

Инфраструктура

Благодаря опыту работы с другими проектами, Пьер Швейцер (Pierre Schweitzer) решил попытаться пропустить исходный код ReactOS через утилиту статического анализа cppcheck, и посмотреть что из этого получится. В результате от него стройным потоком пошли исправления утечек памяти, как непосредственно в ReactOS, так и в разработанных для него инструментах и приложениях, включая уходящий на заслуженный отдых RBuild. Сейчас, для существенного ускорения сканирования, Пьер не подвергает анализу файлы заголовков основных программ, драйверов, а так же родных инструментов разработки.

Команда также усердно работала над объединением всех частей новой среды сборки на основе CMake, готовясь к отказу от RBuild. Первоначально разработчики намеревались включить в среду сборки ещё и GCC 4.6, но способ, которым в GCC toolchain экспортируются различные встроенные функции, доставил им немало проблем и помешал переключиться на использование GCC. У ReactOS имеются собственные встроенные функции, а их экспорты находятся в библиотеке kernel32, но экспорты GCC находятся в его библиотеке mingwex. В результате, компоновщик обнаруживал два одинаковых экспорта для одной и той же функции, что приводило к сбою компоновки бинарных файлов. Кроме того, версия среды сборки для Windows будет использовать для установки MSI взамен NSIS, это долгосрочная задача для Даниэля Реймера (Daniel Reimer), который занимается разработкой среды сборки для Windows.

Сборки CMake начали собираться на Windows-машинах, обслуживаемых Олафом Сейкой (Olaf Siejka) ещё некоторое время назад, и команда в настоящее время работает над возможностью сборки и тестирования ReactOS в системе Linux.

Ввод с клавиатуры

В системе имелись жёстко прописанные в коде значения для некоторых скан-кодов, из-за чего нажатия обрабатывались без учета выбранной пользователем раскладки, что нарушало совместимость с любыми раскладками, пересекающимися с жёстко прописанными скан-кодами. Рафал переписал код для обеспечения корректного маппинга на уровне раскладок клавиатуры и намеревается продолжить ранее начатую Яннисом работу по слиянию потоков событий от мыши и клавиатуры в единый поток ввода. Он также планирует решить проблемы с подключением нескольких клавиатур и обеспечить прохождение тестов Winetests, связанных с клавиатурой и мышью.