ROS Newsletter85

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

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

Поддержка тем оформления

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

Поддержка отладки

Проект ReactOS в прошлом имел склонность создавать собственные решения для различных своих нужд, несколько из которых используются уже довольно давно. В качестве двух самых ярких примеров можно назвать систему для сборки ReactOS на основе rbuild и систему управления содержимым RosCMS, используемую на вебсайте. Ещё одним инструментом, дошедшим до нас из ранних дней проекта, является свой формат отладки под названием rsym. Проще говоря, rsym предоставляет лишь чуть больше информации, чем просто номер строки, содержащей конкретную инструкцию, для чего rsym использует информацию о номерах строк, предоставляемую ему GCC по умолчанию. Первоначальным намерением его создателей могло быть желание сделать ядро достаточно компактным, чтобы оно могло поместиться в память на ранних этапах загрузки. Информация о номерах строк, которую добавляет GCC в формате stabs, значительно увеличивает размер получаемого двоичного файла, а rsym представлял собой способ добавить данные о номерах строк и не получить при этом многомегабайтный двоичный файл. Однако уже существует достаточно компактный формат отладочных символов, предоставляющий гораздо больший объём информации, чем просто номера строк кода. Речь идёт, разумеется, о формате отладочных символов DWARF и Арт Йеркс (Art Yerkes) работал над добавлением его поддержки в kdbg, инструмент для отладки ядра, используемый нашими разработчиками, а также в систему автоматического тестирования сборок. Арт сделал значительную часть работы, необходимой для обеспечения разработчиков возможностью используя DWARF получать значения аргументов, передаваемых функциям. Как только остальная часть работы будет закончена, проект сможет полностью отказаться от использования rsym и намного улучшить поддержку отладки ядра и других компонентов ReactOS без значительного изменения размера двоичных файлов.

Драйвер диспетчера монтирования

Стек запоминающих устройств эры NT5/6 состоит из нескольких компонентов, и каждый из них имеет своё назначение. Драйвер диспетчера монтирования mountmgr, как следует из его названия, отвечает за монтирование устройств и регистрацию их в пространстве имён устройств операционной системы, что позволяет ей использовать их самостоятельно и предоставить доступ к ним пользователю. В архитектуре NT4 этим занималось ядро системы. В этом отношении архитектура NT4 в ReactOS соблюдалась достаточно точно до тех пор, пока Пьер Швейцер (Pierre Schweitzer) не начал работу над нашей собственной реализацией драйвера mountmgr. Одной из дополнительных особенностей mountmgr является возможность смонтировать том в виде каталога, так же, как в Linux. К сожалению, данная функциональность требует более совершенной файловой системы, чем FAT, поэтому пройдёт ещё довольно много времени, прежде чем мы сможем использовать эту возможность в ReactOS. Остальная часть стека хранения просто регистрирует обратные вызовы к диспетчеру plug-n-play для уведомления его о монтировании нового тома. Другие драйверы в стеке запоминающих устройств также необходимо обновить для их взаимодействия с драйвером mountmgr, хотя если их обновление невозможно, уведомления для этих драйверов вполне можно сфальсифицировать. Йоханнес Андервальд (Johannes Anderwald) особенно заинтересован в результатах этой работы, поскольку это очень важный элемент в головоломке поддержки накопителей для порта USB.