Перевод 85 выпуска новостей проекта ReactOS
Доступен перевод 85 выпуска новостей проекта ReactOS, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003).В выпуске:
- Поддержка тем
Яннис завершил разработку поддержки прорисовки в большинстве зон окна, включая заголовки, границы и полосы прокрутки. Наиболее сложными в разработке оказались полосы прокрутки, поскольку программный код, обрабатывающий расчёты при прокрутке, также отвечает за перерисовку изменений окна. Он представлял собой крайне печальное зрелище, состоящее из многократно повторяющихся частей кода прорисовки внутри функции обновления окна при прокрутке его содержимого. Из-за этого удобочитаемость кода значительно снизилась, хотя на данный момент Яннис не испытывает каких-либо проблем с ним.
Следующим шагом станет создание процедур-ловушек пользовательского режима, которые позволят функционировать в ReactOS созданному Яннисом коду, отвечающему за прорисовку тем. В настоящее время большая часть работ по тестированию этого кода производится в Windows.
- Поддержка отладки
Проект ReactOS в прошлом имел склонность создавать собственные решения для различных своих нужд, несколько из которых были созданы уже довольно давно. В качестве двух самых ярких примеров можно назвать систему для сборки ReactOS на основе rbuild и систему управления содержимым RosCMS, используемую на веб-сайте. Ещё одним инструментом, дошедшим до нас из ранних дней проекта, является свой формат отладки под названием rsym. Проще говоря, rsym предоставляет чуть больше информации, чем просто номер строки, содержащей конкретную инструкцию и фактически был сгенерирован с использованием информации о номерах строк, которую GCC предоставляет по умолчанию.
Первоначальным стимулом для этого могло быть желание сделать ядро достаточно компактным, чтобы оно могло поместиться в память на ранних этапах загрузки. Информация о номерах строк, которую добавляет GCC, значительно увеличивает размер результирующего двоичного файла, и rsym представлял собой способ добавить данные о номерах строк и не получить при этом многомегабайтный двоичный файл. Отладочные символы имеют формат DWARF и Арт Йеркс (Art Yerkes) работал над добавлением их поддержки в kdbg, инструменте для отладки ядра, используемом нашими разработчиками, а также в системе автоматического тестирования.
Арт сделал значительную часть работы, необходимой для обеспечения разработчиков возможностью получать значения аргументов, передаваемых функциям, используя DWARF. Как только остальная часть работы будет закончена, проект сможет полностью отказаться от использования rsym и получить значительно лучшую поддержку отладки ядра и других компонентов ReactOS без значительных изменений размера двоичных файлов.
- Драйвер монтирования
Стек запоминающих устройств эры NT5/6 состоит из нескольких компонентов, и каждый из них имеет своё назначение. Драйвер диспетчера монтирования mountmgr, как следует из его названия, ответственен за монтирование устройств и регистрацию их в пространстве имён устройств операционной системы, что позволяет ей использовать их самостоятельно и предоставить доступ к ним пользователю. В архитектуре NT4 этим занималось ядро системы. ReactOS обычно следует архитектуре NT4, однако Пьер Швейцер (Pierre Schweitzer) работал над несколько изменённой реализацией драйвера moutmgr.
Одной из дополнительных функций moutmgr является возможность смонтировать том в виде папки так же, как в Linux, однако данная функциональность требует более совершенной файловой системы, чем FAT, поэтому пройдёт ещё довольно много времени, прежде чем мы увидим в ReactOS эту возможность. Остальная часть стека хранения просто регистрирует обратные вызовы диспетчера plug-n-play для уведомления его о монтировании нового тома.
Другие драйверы в стеке запоминающих устройств также необходимо обновить для их взаимодействия с драйвером mountmgr, хотя, если их обновление невозможно, уведомления для этих драйверов вполне можно сфальсифицировать. Йоханнес Андервальд (Johannes Anderwald) с нетерпением ожидает результатов этой работы, поскольку она представляет собой ещё одну часть в головоломке поддержки накопителей для порта USB.
Полный текст статьи читайте на OpenNet
