Доступен перевод 92 выпуска (http://www.reactos.org/ru/newsletter_92.html) новостей проекта ReactOS, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003).
Улучшения в Win32Глубоко в GDI находится код, предназначенный для обработки ряда растровых операций, в том числе применения шаблонов к растровым изображениям. Для повышения производительности крайне желательно иметь оптимизированные версии этого кода для различной глубины цвета изображений. В действительности же, в ReactOS имелось всего несколько таких версий кода для трёх наиболее часто используемых операций, а остальные операции производились одним и тем же неоптимизированным кодом. Со старым кодом, к тому же было крайне сложно работать и Тимо Кройцер (Timo Kreuzer) предпринял две попытки исправить ситуацию.
Первая попытка закончилась неудачей, однако Рафал Харабиен (Rafał Harabień) смог убедить Тимо в необходимости продолжения этой работы и Тимо удалось создать улучшенный способ генерации оптимизированных функций для всех растровых операций. Тимо разделил все растровые операции на категории исходя их того, какие данные им нужны в качестве входных, выходных и/или шаблонов. Например, для операции инвертирования не требуется шаблон. На основе этих категорий Тимо может удалять неиспользуемый код при генерации функции. Полученный программный код позволяет генерировать около 1200 оптимизированных функций растровых операций.
Ещё одним небольшим, но очень важным изменением, над которым работал Тимо, является переключение большей части подсистемы win32k на использование программных операций с плавающей точкой, возможность которого он добавил в кодовую базу ещё несколько лет назад. Состояние модуля обработки операций с плавающей точкой (FPU) не сохраняется в режиме ядра, поэтому использование FPU в режиме ядра является не самой хорошей идеей. Для решения этой проблемы нужна была лишь оригинальная работа Тимо по добавлению поддержки программной обработки операций с плавающей точкой, однако переход на её использование в большей части кода, например, при координатных преобразованиях, был произведён лишь недавно. Более специализированные функции прорисовки, такие, как построение дуг, до сих пор используют FPU.Исключения, прерывания и ловушки
Некоторое время назад команда ARM переписала значительную часть кода поддержки низкоуровневых операций с ассемблера на язык C. Необходимость этого переписывания была вызвана желанием сделать этот код более гибким и читаемым, что, разумеется, очень хорошо, однако, к сожалению, в созданный ими код вкралось несколько ошибок и неточностей. Наверное самой раздражающей из них для некоторых тестеровщиков была ошибка, выражавшаяся в невозможности останова системы и входа в отладчик при присоединённом WinDBG во время отладки ReactOS. Одной из куда более серьёзных проблем была ошибка, из-за которой модуль обработки операций с плавающей точкой отключал прерывания, а после завершения своей работы не включал их вновь. И всё это лишь малая часть ошибок, которые устранил Стефан Гинсберг (Stefan Ginsberg) после возвращения в проект.
Вероятно, самым большим хаком, удалённым Стефаном, стал код, допускавший повреждение страниц памяти при запрещённых прерываниях. Этого не должно происходить, так как при обращении диспетчера памяти к сохранённым на диск страницам памяти, он должен использовать стек драйверов устройств, использующий прерывания практически для всех операций. Этот хак был удалён после того, как Стефан при помощи Тимо обнаружил основную причину повреждений. Фактически, код обработчика ловушек, вызывавший повреждения страниц, не разрешал прерывания до завершения своей работы за исключением случаев, когда прерывания были запрещены ещё до начала работы кода обработчика ловушек.
Стимулирующим фактором для поиска решения этой проблемы стала ситуация, приводившая к повреждению страниц невыгружаемого пула памяти, что само по себе невозможно, поскольку невыгружаемый пул всегда резидентно находится в памяти. Стефан считал, что это происходит из-за неполной инициализации и отображения записей системных таблиц и каталогов страниц невыгружаемого пула для всех процессов в старом диспетчере задач, поэтому процесс мог считать, что принадлежащая ему страница памяти повреждена во время доступа к невыгружаемому пулу, хотя в действительности причиной этого были лишь неправильные значения в записи таблицы страниц. К счастью, диспетчер памяти ARM3 не был подвержен этой проблеме.
Однако в системе всё ещё осталось несколько проблем разной степени важности. В ReactOS в рудиментарном виде имеется поддержка мультипроцессорных систем, которая хоть и не позволяет полноценно использовать все возможности многопроцессорных или многоядерных систем, однако даёт возможность запускать операционную систему на такой платформе, используя лишь один процессор/ядро. Похоже что в этом коде, после перехода с ассемблера на использование C, также содержится ошибка, хотя Стефан никак не может её обнаружить. Куда гораздо более серьёзной проблемой является то, что ReactOS портит содержимое стека при пошаговом выполнении инструкций во время отладки. Эта проблема, как полагает Стефан, возникла при переписывании кода поддержки ловушек, хотя точно в этом он не уверен.Прощание с Pageop
Несколько лет назад состоялся разговор с Артом Йерксом (Art Yerkes) о состоянии и проблемах диспетчера памяти ReactOS. Одной из самых крупных архитектурных проблем было использование операций под названием pageop, представлявших собой довольно необычную попытку разрешения конфликтов при одновременном доступе к элементу таблицы страниц. Когда диспетчер памяти принимает решение о необходимости сохранения страницы на диск, всегда существует возможность того, что этот процесс может быть прерван или другой поток может предпринять попытку изменить состояние или содержимое этой страницы. В этом случае, если доступ не синхронизирован, это действие может привести к повреждению данных.
Операции pageop были предназначены именно для исключения вероятности повреждения данных, для чего они следили за состоянием обработчика ошибок. Для хранения состояния pageop могло потребоваться выделение дополнительной памяти, что привело бы к проблемам в том случае, если диспетчер памяти попытается выгрузить страницы на диск, чтобы освободить память. Проведя довольно большую и сложную работу, а также выслушав предложения от Алекса Ионеску (Alex Ionescu) и Трэвиса Гейзельбрехта (Travis Geiselbrecht) из NewOS, Арт наконец нашёл более простой и практичный способ синхронизации одновременного доступа при операциях с элементами таблиц страниц.Инструментарий для сборки
Одной из жалоб, появившихся после перехода на использование CMake, является медленная, по сравнению с RBuild, сборка системы. Частично эту медлительность можно списать на то, что CMake гораздо лучше проверяет зависимости, чем RBuild, что, несомненно, очень и очень хорошо. Чтобы хоть немного смягчить эту проблему, была начата работа, включающая в себя улучшение поддержки предварительно откомпилированных заголовков в самом CMake, а также переход на новую систему сборки под названием ninja.
Система ninja была создана разработчиком Chromium Эваном Мартином (Evan Martin) для обеспечения возможности как можно более быстрой сборки. Сборочные файлы ninja изначально созданы таким образом, что могут быть сгенерированы системой высокого уровня, такой, например, как CMake, а это как раз то, что нужно проекту ReactOS. Амин Хальди (Amine Khaldi) знаком с ninja уже в течение некоторого времени, и работал над возможностью сборки ReactOS с помощью этой системы. Поскольку ninja ещё очень молодой проект, в нем имеется достаточно много отсутствующих функций. На данный момент самым большим недостатком является отсутствие поддержки зависимостей MSVC, которая в ninja находится в стадии разработки. До настоящего времени проект ReactOS успешно сотрудничал с множе...URL: http://www.reactos.org/ru/newsletter_92.html
Новость: http://www.opennet.me/opennews/art.shtml?num=33965
Молодцы!
Да, конечно. Пока у них полудохлый диспетчер памяти и несовместимость с проприерастичными дровами (на которые они кивали как на "фичу") они занимаются переходом с одной системы билдования на другую, а потом осознав что результат не нравится - еще и NIHом.Осталась только сущая ерунда - убедить окружающих что им полудохлая система с таким букетом проблем вообще нужна. Если надо запустить виндовую программу и сегодня - вайн и то менее криво будет.
>Глубоко в GDI находится код, предназначенный для обработки ряда растровых операций, в том числе применения шаблонов к растровым изображениям.Ну блин, прямо начало фантастического блокбастера...
упс. то же самое написал. надо сначала каменты читать, да…
такое ощущение что костыли над костылями )
> такое ощущение что костыли над костылями )ну дык. проект изначально был костыльный. по уму, конечно, его надо выкинуть весь и переписать заново с учётом всех известных граблей, но… понятно, что никто не станет.
>по уму, конечно, его надо выкинуть весь и переписать зановоНет, его надо просто выкинуть весь и точка.
> Нет, его надо просто выкинуть весьзачем? проект как проект, ничем не хуже соседнего OpenMW.
> такое ощущение что костыли над костылями )Неправда, там еще грабли есть. Целый лес грабель. Мечта мазохиста!
Буду тривиален - RectalOS не нужна.
Да пускай будет, они с вайном обмениваются кодом.
> Да пускай будет, они с вайном обмениваются кодом.Городские легенды
>> Да пускай будет, они с вайном обмениваются кодом.
> Городские легендыне, таки насколько я знаю, «обмениваются». в смысле, реактор периодически пытается что-нибудь из вайна утащить.
К черту болтовню, покажите код!
(с) Линус Торвальдс.
Дык иди скачай
>>Наверное самой раздражающей из них для некоторых тестеровщиков была ошибка, выражавшаяся в невозможности останова системы и входа в отладчик при присоединённом WinDBG во время отладки ReactOSИ пока не нашли ошибку, ни один разработчик не дебажил продукт.
> И пока не нашли ошибку, ни один разработчик не дебажил продукт.есть подозрение, что после нахождения ошибки ситуация особо сильно не поменялась.
> Глубоко в GDI находится код, предназначенный для обработки ряда растровых операций…просто начало какой-то древней легенды. «далеко-далеко в горах…»
> просто начало какой-то древней легенды. «далеко-далеко в горах…»"Давным давно, в далекой галактике..."
> тщательное тестирование
> ReactOSdivided by zero.
> divided by zero.Пока они тщательно тестируют, у них в системе не запускается почти ничего из тех проприерастических драйверов на которые они кивали как на "плюс" такого подхода.
В результате система может и годится чтобы подро^W на нее в виртуалочке, но на реальном железе оно являет собой довольно бесполезный артефакт.
В свете такого расклада я бы заменил слово "тщательно" на "тщетно". Так было бы честнее...
А Linux лучше типа? До сих пор X-Server падает если ему драйвер видяхи не понравился, или на стройки, и если случилось лезь в консоль - убивай конфиг. Сколько лет-то пилят, а простой функции, как запустить x-server с умолчательными параметрами, пусть и с кривым разрешением нет. Так что чья-бы корова мычала...