0,1
рейтинг
19 декабря 2011 в 17:08

Выпуск новостей ReactOS #89 перевод

image
RPC

Вызов удалённых процедур (Remote Procedure Call) включает в себя множество различных компонентов Windows, в особенности службы. Таким образом динамическая библиотека вызова удалённых процедур (rpcrt4) имеет довольно важное значение для обеспечения непрерывного функционирования и стабильности ReactOS. Кроме того, она является компонентом, в котором проект крайне зависим от Wine. К сожалению то, что код Wine работает в Linux, ещё не означает, что он будет работать в ReactOS, и все предыдущие попытки синхронизировать rpcrt4 приводили к множеству проблем и сбоев в ReactOS. Томас Фабер (Thomas Faber), студент, участвовавший в Google Summer of Code с проектом по реализации новой системы для тестирования компонентов ядра, обнаружил, как он полагает, основную причину возникновения критических сбоев RPC в ReactOS. Когда процесс совершает вызов удалённой процедуры, он получает дескриптор этого вызова. Этот дескриптор представляет собой уникальный идентификатор каждой операции RPC, а его уникальность должна был быть гарантирована генератором случайных чисел. Wine для этих целей использует генератор случайных чисел Linux, расположенный в /dev/urandom, которого в ReactOS, разумеется, нет. В дополнение ко всему прочему, оказалось что в коде ReactOS отсутствует функция NT, которую Wine использует для генерации случайных чисел, поэтому при запросе на получение уникальных идентификаторов для разных операций RPC могли выдаваться одинаковые значения. Это приводило операционную систему в замешательство и ломало функциональность всего, что зависело от RPC. Томас занимается этой проблемой, и, мы надеемся, что в будущем попытки синхронизировать rpcrt4 с кодом Wine не будут приводить к катастрофическим последствиям для операционной системы.

Диспетчер памяти


Многие тестеры высказывали своё недовольство по поводу зависания процесса установки ReactOS во время попытки копирования файла mshtml.dll. Попытки диагностировать проблему привели разработчиков глубоко в недра диспетчера памяти и выявили довольно широкий круг проблем. Причина зависания заключалась в обнулении структур данных, что приводило к тому, что диспетчер кучи терял способность отслеживать блоки памяти во время копирования файла mshtml.dll. Без этой информации диспетчер кучи не мог получить следующий блок памяти и зависал в бесконечном цикле. Уже третья (а может и того больше) команда разработчиков попробовала свои силы в устранении этой проблемы, и все они приходили к одинаковому выводу: переписывание диспетчера памяти, начатое в ARM3, должно быть завершено. Томас был одним из участников команды по устранению этой проблемы, и вначале решил, что ошибка вызвана компонентом setupapi, который производит установку драйверов, библиотек, и связанных файлов. Это было обусловлено довольно захламлённым состоянием и сложностью кода setupapi, поэтому Томас предположил, что ошибка возникает из-за переполнения памяти и тому подобных проблем. Для проверки этой теории Томас создал свой собственный диспетчер кучи и запустил setupapi поверх него. В результате setupapi был реабилитирован, поскольку начали появляться сбои, не связанные с setupapi. Это означало, что проблема находится куда гораздо глубже в диспетчере памяти. Ещё большим разочарованием стало то, что сбои, похоже, зависели от тайминга, что само по себе предполагало вероятный конфликт ресурсов.

В Крестовом походе на MSHTML принимал участие и Кэмерон Гутман (Cameron Gutman), однако ему пришлось отвлечься на патч, предоставленный Николаем Мыльцевым и связанный с работой подкачки. Вообще, объём виртуальной памяти, затребованный приложением, и объём этой памяти, в действительности находящейся в физической памяти, это две разные вещи. В Windows, рабочий набор представляет собой страницы виртуальной памяти процесса, с которыми недавно происходила работа, и для всех процессов имеются максимальный и минимальный размеры рабочего набора. Windows попытается сохранить рабочий набор страниц в физической памяти, предполагая, что для этого имеется достаточно свободного места. Предназначением рабочего набора является предотвращение поглощения всей физической памяти одним приложением, и диспетчер памяти балансирует потребление памяти каждого из процессов путем изъятия страниц из рабочих наборов разных процессов, если в этом возникает необходимость. Страницы, содержимое которых было изменено в оперативной памяти, должны быть записаны обратно на диск до того, как занимаемый ими блок памяти может быть использован повторно. Когда приходит время для изъятия страниц из рабочего набора, операционная система будет искать достаточное количество чистых, немодифицированных страниц, которые она могла бы повторно использовать, получая тем самым необходимое количество свободной памяти. Система должна также постараться записать изменения в занятых страницах, если в её распоряжении имеется недостаточное для удовлетворения запроса на выделение памяти количество свободных страниц, однако как раз этого в ReactOS и не происходило. Эта ошибка в конечном итоге приводила к тому, что у балансировщика рабочего набора заканчивались страницы, которые он мог бы изъять из рабочего набора, в результате чего происходил критический сбой операционной системы. Просмотрев созданный Николаем патч и сделав в нём несколько своих изменений, Кэмерон добавил результаты своей работы в кодовую базу проекта, и теперь балансировщик корректно записывает изменения в занятых страницах, что позволяет использовать их повторно.

Микрокоды процессора


Эта тема требует небольшого экскурса в проектирование и изготовление ЦП. Большинство программистов понимает, что каждое из семейств процессоров подчинено своей архитектуре набора команд (Instruction Set Architecture), определяющей, какие инструкции и операции процессор может выполнить. Однако многие люди не знают или не задумываются, что большинство процессоров на самом деле не выполняют инструкции, определённые ISA, напрямую. В действительности существует более низкий уровень команд, это так называемые микрокоды, которые управляют работой процессора таким образом, чтобы результат соответствовал требованиям ISA. Эти микрокоды по большей части абсолютно недокументированы, поскольку и у AMD и у Intel они представляют собой коммерческую тайну. Архитектура современных ЦП чрезвычайно сложна, и в ней могут существовать аппаратные ошибки, приводящие к неправильной обработке микрокода. Устранение такой проблемы в аппаратных средствах потребовало бы изменения архитектуры, но в современных ЦП возможно исправить эти ошибки, обновив микрокод. AMD и Intel предоставляют эти патчи разработчикам операционных системы в виде двоичных файлов, но процесс, в котором Windows применяет эти патчи, недокументирован. Пьер Швейцер (Pierre Schweitzer) занялся этим вопросом и у него возникли некоторые мысли относительно того, как ReactOS может обновлять микрокод, но на данный момент проблема имеет довольно низкий приоритет. В любом случае, это довольно интересная проблема, выделяющаяся рядом сложностей, с которыми можно встретиться на самых низких уровнях аппаратных/программных интерфейсов.

Установка


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

S/G DMA

В традиционных операциях прямого доступа к памяти (DMA) необходим единый непрерывный блок памяти, в который будут передаваться данные. К сожалению, не всегда в распоряжении системы имеется достаточно большой блок памяти. Прямой доступ к памяти по механизму «Scatter/Gather» призван исправить эту проблему путём использования кусков меньшего размера, сохраняя данные об их размещении и записывая данные в них. Основная часть кода поддержки S/G DMA уже имелась в ReactOS, однако API, который представлял бы её функциональность, отсутствовал. Кэмерон взялся и разработал этот API, что позволило работать в ReactOS драйверам, использующим механизм S/G DMA, по большей части это драйверы сетевых карт.

Оптимизации памяти во FreeLoader


Недавно Тимо Кройцер (Timo Kreuzer) заметил, что freeldr довольно неэффективно использует память. Фактически существует два типа данных, для которых freeldr требуется память: данные, которые передаются им ядру, и данные, которые необходимы лишь самому freeldr для завершения загрузки операционной системы. Первоначально freeldr выделял единый блок размером 4 Мб и использовал его для обоих типов данных, при этом ядру приходилось читать все 4 Мб данных. Посчитав это несколько расточительным, Тимо разбил единый кусок на две разные кучи, по одной для каждого типа данных. Это позволяет freeldr освобождать всю память, не имеющую отношения к ядру, что приводит к существенному уменьшению количества занятой памяти. Вроде бы небольшое изменение, однако такие небольшие изменения, как это, могут многое изменить в долгосрочной перспективе.

Исправления путей


Множество регрессий, вызванных новым загрузчиком, были связаны с не совсем верным поведением некоторых функций, имеющих дело с путями. Поскольку загрузчик во время своей работы совершает множество операций доступа к файлам, необходимым для загрузки исполняемых файлов и библиотек, он активно использует функции обработки путей. Алекс Ионеску (Alex Ionescu) недавно уделил время переписыванию большой части основных функций, связанных с различиями кодировки строк и их преобразованием, парсингом сокращений и исправлением кодов ошибок при критических сбоях. Всё это вместе взятое вылилось в устранении значительного количества регрессий, связанных с загрузчиком, и, надеемся, позволит ещё большему количеству приложений функционировать корректно.

P.S. В переводе участвовали: evilslon, serrox, tipys.

P.P.S. Проект принимает пожертвования теперь и в биткоинах www.reactos.org/ru/foundation_donate.html
Перевод: Z98
Речицкий Александр @Jeditobe
карма
37,7
рейтинг 0,1
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое

Комментарии (34)

  • +13
    Ждем ReactOS 3.14 (Pi)! =)
  • –29
    Забавно наблюдать, как группа людей изобретают велосипед. Интересно, когда же ждать стабильную ОС? Надеюсь, это не риторический вопрос :)
    • –26
      Спасибо за карму.
      • –23
        Кстати, что я такого написал? Плохо не отзывался, говном не называл. Сарказма не было. Да плевать уже…
        • НЛО прилетело и опубликовало эту надпись здесь
          • –10
            Просто я скептически отношусь к данной разработке. Сам WIn очень далеко убежал вперед, что ставит под угрозу весь проект. Мне кажется, что к релизу ReactOS останется мало актуального программного продукта. Но сейчас я не могу ее даже запустить. 3 машины, не пошла ни на одной.
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                Думаю, найдет свое применение. До сих пор остался спрос на win95-98, а на переписанную NT/XP будет много желающих, даже я :) Вот только быстрее бы. Ребятам нужен какой то ход конем, что то предложить такое, что в винде нет. Не видел ни одного покупного XP за последние 3 года.
                • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    В том и проблема, что нет уверенности в данный момент, а вышеперечисленный софт и на ubuntu легко запускается.
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • +2
                        Вы так говорите, как будто реактось запускает сильно больше софта, чем wine.
                        • 0
                          Цель же что было больше, нет?
                          • 0
                            Пока что меньше. Ощутимо меньше. Но продукт ещё очень сыр и это понятно.
                  • +1
                    Я думаю им можно ориентироваться только на офисы. Всевозможные жёлтые программы и косынки живут веками в офисах, и ни чего их не берёт! Даже если и ставить покупные пакеты от мс с офисом, то для конторы которая любит белый софт, это будет экономия т.к. они покупают только его! А терминалы? На кассах которые так же связаны в сеть с жёлтой программой? Их же тысячи! Конечно надо помнить про другие проекты с кодами вина в своём наборе.
                  • +3
                    В своих рассуждениях Вы упустили важную часть: «За идейную основу РеактОС взято ядро Вин2003 сервер».
                    Именно бесплатный ВинСервер и нужен больше всего! Потому как политика лицензирования серверов у Микрософта — просто вымогательская.
                • +2
                  А в фирмах? Их-то обязывают использовать лицензионное ПО, проверяя и карая штрафами.
          • –1
            А теперь я «приоткрою».
            В Windows используется большое количество запатентованных технологий Microsoft, без которых нормальная поддержка программ будет невозможна.
            Смею предположить, что у «этих ребят» нету прав на их использование. Как только разрабы Реакта получат с этого хоть какой-то доход, Microsoft сможет взять в рабство их и членов их семей.

            А что можно сказать о самой ОС, так мы подобных проектов уже понавидали пачками. Нормальной работы с более-менее серьёзным софтом не ждите. Более того, ниодна серьёзна организация, не станет заменять Windows (даже пиратский) на «это вон».

            Так что, вполне можно понять скептицизм по отношению к данному проекту.
            • +3
              Насчет «В Windows используется большое количество запатентованных технологий Microsoft» — не забывайте, что в России и ЕС не действуют патенты на ПО, за исключение ряда случаев, навряд ли относящихся к Windows:

              Гражданский кодекс РФ
              Статья 1350. Условия патентоспособности изобретения
              «5. Не являются изобретениями:

              2) научные теории и математические методы;

              5) программы для ЭВМ;»

              Wikipedia/Software patents under the European Patent Convention
              • 0
                К сожалению
                а) это может измениться со временем (из-за вступления в ВТО)
                б) не хочется обрекать реактос на чисто русское (+ ещё несколько) существование. Это плохо как для проекта (меньше разрабов), так и для нас (кто знает как на нас повлияет такая «халява»: несколько потенциально отрицательных последствий, связанных как с никсами, так и с имеджем вижу я)
                • 0
                  Система софтверных патентов существует только в США и Японии. Причём даже в США она «трещит по швам», нужно быть полными идиотами, чтобы повторить американскую «историю успеха», это все прекрасно понимают. Так что ваше словосочетание «чисто русское существование» слегка натянуто… скажем так.
            • +1
              В Windows используется большое количество запатентованных технологий Microsoft,
              Вы имеете ввиду такие высокотехнологичные патенты как «даблклик»? ;-)
          • +1
            немного поправлю. тут дело не в бесплатности системы (полностью бинарно-совместимой с виндовс), а ее открытостью. free as in speech
        • +5
          Люди годами работают, а вы такой умный обозвали плод их труда велосипедом. Ну-ну
    • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
      • +10
        А то что под эту ОС получает из коробки уже куча написанного и востребованного ПО — не аргумент?
      • +2
        Главное, насколько я понимаю, обеспечить совместимость с API Windows, возможно даже не документированными. Внутри он может быть мегакрутойсуперпупер, снаружи блекджек и шлюхи, но главное чтобы программы запускались нормально.
  • +3
    Я вот все жду новости в стиле:
    Ранее пользователи были недовольны тем, что многие вирусы не работают на РеактОС, и, в новом релизе, разработчик Рулон Обоев (Piece of Wallpaper) переписал соответвующую часть системы.
  • +7
    Желаю всяческих успехов разработчикам. Киви куда можно перевести?
    • 0
      Все способы пожертвований перечислены на странице www.reactos.org/ru/foundation_donate.html

      Вроде бы можно Киви-Вебмани-РеактОС.
  • +5
    Всегда вызывали восхищение люди, способные на такой титанический труд только ради идеи. Так держать, парни! Вы молодцы.
  • +1
    Молодцы парни, не то что я, только игрушки пишу(
  • 0
    "… в современных ЦП возможно исправить эти ошибки, обновив микрокод. AMD и Intel предоставляют эти патчи разработчикам операционных системы в виде двоичных файлов, но процесс, в котором Windows применяет эти патчи..."
    А как эта проблема решается в Linux и Unix и других OS? AMD и Intel делают массовую рассылку своих патчей к микрокодам всем разработчикам OS?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.