ROS Newsletter46

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

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

Виртуальные папки Проводника

Все специальные папки, такие как "Панель управления", "Принтеры" и "Администрирование", на самом деле являются папками расширения оболочки, которые Проводник реализует, используя интерфейс IShellFolder. Йоханнес Эндерволд (Johannes Anderwald) занимается реализацией отсутствующих в ReactOS расширений, а также работает над уже существующими. Два его новых расширения - папки "Шрифты" и "Администрирование". Также Йоханнес реализовал диалог форматирования дисков, который, конечно, ещё не несёт функциональности.

Текущая реализация Корзины была исправлена Эрве Поссино (Hervé Poussineau). Проблема заключалась в неправильном поведении Trash_CanTrashFile: удалённые файлы не перемещались в Корзину. По сути, это означает, что файлы непосредственно удалялись с диска при подтверждении запроса на удаление. Сейчас это исправлено, так же как восстановление и удаление отдельных файлов из Корзины. Были также некоторые проблемы с папкой "Принтеры", в том числе - отсутствие контекстного меню и выделяемая случайным образом память, теперь же функция EnumPrinter частично реализована, но, пока не готова подсистема печати, полностью рабочей реализации придётся подождать.

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

Исправление ошибок

Одной из неприятных ошибок в ReactOS было крушение системы при прерывании рабочего потока. Рабочий поток - это поток режима ядра, который что-либо делает на стороне драйверов устройств. Существование универсального пула рабочих потоков, поддерживаемых супервизором NT, необходимо, чтобы драйверы могли создавать свои группы потоков для особых нужд. Эту ошибку обнаружил Камерон Гутман (Cameron Gutman) при длительном тестировании работы ReactOS. Проблема была в том, что после нескольких часов работы поток прерывался, что приводило к краху ОС.

Причиной падения системы была неправильно написанная проверка в PspExitThread, которая предполагала крах системы лишь в случае отключения свопинга стека. Функция проверки выдавала значение, противоположное ожидаемому, когда свопинг стека был включён. По иронии, этот недочёт был в тандеме с ещё одной проблемой в KeInitThread. Ошибка характеризовалась неправильным значением флага, отвечающего за включение свопинга стека. По этой причине ошибка не была обнаружена в течение столь длительного времени. Обе проблемы были исправлены Стефаном Гинсбергом (Stefan Ginsberg). Это должно позволить системе дольше оставаться работоспособной. Будут ли эти изменения требовать дальнейших хаков, покажет только время.

Компиляция ReactOS

Существует "волшебный" флаг в GCC, "-enable-stdcall-fixup", который используется при компиляции ReactOS. Этот флаг позволяет создавать псевдонимы функций, не совпадающих по количеству передаваемых параметров. Это, безусловно, плохой стиль программирования, который только способствует возникновению проблем. Но Эрве Поссино (Hervé Poussineau) понемногу исправлял экспорты функций, чтобы в итоге мы могли прекратить использование этого флага GCC. Эти действия вызвали несколько поломок, но, в конечном итоге, Эрве видит в этом наилучший путь исправления ошибок, которые были допущены им самим и остальными. По его словам, все несоответствия уже устранены.

Помимо исправления экспортов, Эрве уже работает над другим вопросом, связанным с компиляцией компонентов ReactOS. Компиляция библиотек является более сложной, чем обычной исполняемой программы. Библиотеки, по сути, это просто набор функций для использования в других приложениях. Вам, конечно, необходимо указать, какие функции Вы хотите позволить использовать, а какие не должны быть общедоступны. Это можно сделать при помощи ключевого слова "export" перед экспортируемой функцией или используя .def-файл со списком экспортируемых функций. Если вы используете метод с .def-файлом, то, по крайней мере для GCC, нужно передать в dlltool имя .def-файла и имя целевой библиотеки. Данные действия приведут к созданию .a-файла, который содержит список функций, вызываемых из библиотеки. Созданный .a-файл используется в тех случаях, когда вы хотите написать программу, которая использует эту библиотеку. LD будет жаловаться, поскольку он не может найти этих функций, но если вы используете при линковке файл .a с объектными файлами, то компиляция пройдёт успешно.

Упомянутые выше .def-файлы различны для GCC и MSVC. Именно поэтому, попытка компилировать библиотеки в MSVC с нашими .def-файлом потерпит неудачу. Чтобы разрешить эту проблему, Эрве сконвертировал все наши .def-файлы в .spec-файлы. Он намерен улучшить Winebuild, программу, которая преобразует .spec-файлы в GCC .def-файлы, с тем, чтобы можно было генерировать .def-файлы для MSVC. Как только это будет сделано, еще одно препятствие для сборки с помощью компилятора от Microsoft будет преодолено. Для тех, кому интересен способ создания библиотеки в MSVC: единственным отличием от GCC является то, что MSVC создает .lib-файлы вместо .a-файлов. Mingw также создает .lib-файлы, так как он компилирует для Windows.

Файловые системы

Как уже упоминалось ранее, проблемы с СС (Common Cache - компонент ОС, отвечающая за кеширование запросов) мешают использовать любую файловую систему, отличную от имеющейся (FAT). На самом деле - даже драйвер FAT был "подогнан" особым образом для обхода этих проблем. Однако, драйверы файловых систем нуждаются не только в должным образом функционирующем СС, необходима также реализация FsRtl - Библиотеки файловой системы. Все драйверы файловой системы ReactOS, используемые в настоящее время, были написаны без использования FsRtl, что делает ситуацию намного сложней, так как драйверы файловых систем должны использовать только этот API. Но, если простейшие файловые системы могут обходиться без использования FsRtl, то для сложных файловых систем, таких как Ext2/3/4 и NTFS, FsRtl просто необходим.

Пока Арт Йеркес (Art Yerkes) и Алексей Брагин (Aleksey Bragin) работют над СС, Пьер Швейцер (Pierre Schweitzer) создал ветку в репозитарии для реализации FsRtl и испытаний драйвера Ext2 от Matt Wu. Одна из возможностей FsRtl, над которой Пьер работает в настоящее время, является уведомление об изменении каталога, отсутствие данного уведомления в настоящее время приводит к самопроизвольному обновлению рабочего стола. К тому же, FsRtl, возможно, является одной из наименее исследованных API в NT и даже со специальной документацией для разработчиков файловых систем остаётся много белых пятен в реализации оригинальной библиотеки. В настоящее время, Пьер проводит исследования, стараясь узнать, что происходит при вызове различных функций в различных обстоятельствах. Этот метод исследования называется blackboxing и используется несколькими разработчиками ReactOS.

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