The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

88 выпуск новостей проекта ReactOS

15.10.2011 03:07

Доступен перевод 88 выпуска новостей проекта ReactOS, операционной системы с открытым исходным кодом, нацеленной на обеспечение совместимости с программами и драйверами Microsoft Windows семейства NT (XP/2003).

Shell32

Ещё одним достижением Клаудиу Михаила (Claudiu Mihail), который в рамках недавнего Google Summer of Code преобразовал библиотеку IwIP в драйвер, стало окончание работ по переписыванию библиотеки shell32 с языка C на C++ и интеграция полученного программного кода в транк. Работы по преобразованию были начаты Гедом Мёрфи (Ged Murphy) и Эндрю Хиллом (Andrew Hill), и цель их проведения состояла в том, что C++ наилучшим образом подходит для реализации различных аспектов механизма COM в этой библиотеке. Сначала Гед попытался сконвертировать код непосредственно в транке, однако оказалось, что в этом случае поддерживать целостность кода в транке весьма сложно, и Гед переместил свои наработки в отдельную ветвь. Клаудиу, после завершения своего проекта GSoC, продолжил его работу и доработал код.

Перевод кода с C на C++ нередко выявляет ошибки в коде, такие например, как не заданные значения по умолчанию для элементов класса в конструкторе или некорректно выполненные обновления элементов класса. Одной из самых больших проблем, требовавших исправления, являлось то, что апплеты Панели управления не запускались. Эта проблема возникла после того, как Клаудиу внёс исправления в парсер командной строки для обеспечения прохождения тестов Wine. Парсер корректно уменьшал названия апплетов до их короткой формы, например с "Add Hardware" до "Add", однако из-за проблемы в глубине кода библиотеки, система не могла найти апплеты Панели управления по их коротким именам.

Когда эта проблема была устранена, оказалось, что из-за других ошибок в библиотеке ATL невозможна правильная регистрация расширений в оболочке. Яннис Адамопулос (Giannis Adamopoulos) тоже обращал внимание на проблемы с регистрацией, но так и не смог решить их. Кроме того, Йоханнес Андервальд (Johannes Anderwald) также тщетно пытался справиться с этой проблемой, и заявил, что ATL является неподходящим механизмом для регистрации расширений оболочки. Тем временем Амин Хальди (Amine Khaldi) сделал откат изменений в коде регистрации, что позволило использовать старый механизм регистрации, взятый из Wine и являющийся хоть и архитектурно неправильным, но, по крайней мере, хоть немного работоспособным.

Поскольку корректная реализация shell32 никогда не являлась приоритетной задачей для Wine, то и тестов в наборе winetests для проверки этого компонента очень мало. Клаудиу работает над этим и уже добавил несколько новых тестов для проверки большего количества функций библиотеки. Совместно с Виктором Мартинесом (Victor Martinez) было добавлено несколько тестов для проверки парсера командной строки, а тесты для других составных частей библиотеки, надеемся, скоро также появятся.

Исправления в загрузчике

Прошло уже несколько месяцев с тех пор, как Алексей Брагин добавил в основную кодовую базу результаты своей работы по переписыванию загрузчика, что привело к появлению в системе большого количества регрессий. Однако, как минимум одна из регрессий была связана с маркерами безопасности (security cookies). Они не имеют ничего общего с cookies, используемыми при интернет-сессиях, а предназначены для вызова соответствующих функций для обнаружения повреждений памяти. Повреждения памяти и тому подобные проблемы могут произойти как в стеке, так и в куче. Тем, кто не знает, чем стек отличается от кучи, вкратце можно пояснить, что стеком называется то место, где хранятся все локальные переменные функций, в то время как куча представляет собой источник динамически распределяемой памяти.

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

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

Отладочный пул

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

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

Инфраструктура

Благодаря опыту работы с другими проектами, Пьер Швейцер (Pierre Schweitzer) решил попытаться пропустить исходный код ReactOS через утилиту статического анализа cppcheck, и посмотреть что из этого получится. В результате от него стройным потоком пошли исправления утечек памяти, как непосредственно в ReactOS, так и в разработанных для него инструментах и приложениях, включая уходящий на заслуженный отдых RBuild. Сейчас, для существенного ускорения сканирования, Пьер не подвергает анализу файлы заголовков основных программ, драйверов, а так же родных инструментов разработки.

Команда также усердно работала над объединением всех частей новой среды сборки на основе CMake, готовясь к отказу от RBuild. Первоначально разработчики намеревались включить в среду сборки ещё и GCC 4.6, но способ, которым в GCC toolchain экспортируются различные встроенные функции, доставил им немало проблем и помешал переключиться на использование GCC. У ReactOS имеются собственные встроенные функции, а их экспорты находятся в библиотеке kernel32, но экспорты GCC находятся в его библиотеке mingwex. В результате, компоновщик обнаруживал два одинаковых экспорта для одной и той же функции, что приводило к сбою компоновки бинарных файлов. Кроме того, версия среды сборки для Windows будет использовать для установки MSI взамен NSIS, это долгосрочная задача для Даниэля Реймера (Daniel Reimer), который занимается разработкой среды сборки для Windows.

Сборки CMake начали собираться на Windows-машинах, обслуживаемых Олафом Сейкой (Olaf Siejka) ещё некоторое время назад, и команда в настоящее время работает над возможностью сборки и тестирования ReactOS в системе Linux.

Ввод с клавиатуры

В прошлом году Яннис работал над поддержкой сообщений от мыши. В этом году, Рафал Харабиен (Rafał Harabień) решил заняться клавиатурной частью поддержки устройств ввода. Для определения того, какая клавиша была нажата, клавиатура отправляет на компьютер скан-код. Эти скан-коды затем обрабатываются с учётом используемой раскладки клавиатуры, таким образом операционная система и приложения узнают, какую букву или специальную виртуальную клавишу нажал пользователь. Как и в немалой части других компонентов ReactOS, в коде поддержки клавиатуры содержалось немало проблемных мест.

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

  1. Главная ссылка к новости (http://www.reactos.org/ru/news...)
  2. OpenNews: 87 выпуск новостей проекта ReactOS
  3. OpenNews: 86 выпуск новостей проекта ReactOS
  4. OpenNews: Перевод 85 выпуска новостей проекта ReactOS
  5. OpenNews: Релиз открытой операционной системы ReactOS 0.3.13
Автор новости: 1111
Тип: Обобщение
Ключевые слова: reactos
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (19) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (-), 10:02, 15/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Молодцы! Жду выгоды обратного портирования фич в wine!
     
     
  • 2.3, Аноним (-), 12:20, 15/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Они этим точно занимались и занимаются?
     
  • 2.8, жабабыдлокодер (ok), 22:17, 15/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    А чего в wine портировать? В ReactOS же WinAPI не исправляют, а аппаратные драйвера для wine не нужны.
     

  • 1.2, Аноним (-), 10:09, 15/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    > Кроме того, версия среды сборки для Windows будет использовать для установки MSI взамен NSIS

    Теперь у них тоже будет убогий и глючный недоменеджер пакетов? :)

     
  • 1.4, Ааноним (?), 12:56, 15/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    кстати, в семёрке "Установка и удаление программ" переименована в более корректное "удаление и изменение", жду когда переименуют в "удаление программ с кучей оставшихся записей в реестре, папке программ и домашних каталогах")
     
     
  • 2.5, Аноним (-), 14:40, 15/10/2011 [^] [^^] [^^^] [ответить]  
  • +3 +/
    >кстати, в семёрке "Установка и удаление программ" переименована в более корректное
    >"удаление и изменение", жду когда переименуют в "удаление программ с кучей оставшихся
    >записей в реестре, папке программ и домашних каталогах")

      О, да, действительно достижение для Windows и MS. Подкиньте MS идею насчет переименования, так как переименования и раскраски - это их уровень и хлеб.
      Ну а вцелом по ReactOS думается мне что он мертворожден. Ко времени когда ReactOS будет что-то стоящее из себя предствлять Linux будет еще более универсален чем сейчас, а из wine сделают настоящий комб-wine. Хотя из ReactOS может получиться продукт который сможет замещать форточки в embedded и маломощных устройствах (чтобы уж совсем с корнем выкорчевать MS и вантуз из IT индустрии).

     
  • 2.21, Клыкастый (ok), 23:26, 17/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    милиция/полиция не ваша идея?
     

  • 1.9, arisu (ok), 00:26, 16/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    неужели за реактор наконец-то берутся те, которые знают, с какой стороны подходить к написанию больших проектов? бедняги. им там, небось, как минимум половину кода придётся заново сделать…
     
  • 1.10, Sw00p aka Jerom (?), 01:12, 16/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >>по переписыванию библиотеки shell32 с языка C на C++

    дальше читать не стал

     
     
  • 2.11, arisu (ok), 01:16, 16/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>>по переписыванию библиотеки shell32 с языка C на C++
    > дальше читать не стал

    зря. для ком цпп действительно удобней, чем ц.

     
  • 2.12, Аноним (-), 02:23, 16/10/2011 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>>>по переписыванию библиотеки shell32 с языка C на C++
    >>дальше читать не стал

    всетаки ооп в плане написания большого объема кода гараздо удобнее и правельнее. но это не в коем случае не камень в огород сей.

     
     
  • 3.13, anon2 (?), 05:38, 16/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>>>>по переписыванию библиотеки shell32 с языка C на C++
    >>>дальше читать не стал
    >  всетаки ооп в плане написания большого объема кода гараздо удобнее и
    > правельнее. но это не в коем случае не камень в огород
    > сей.

    С++ как раз таки совершенно не подходит для больших проектов - сложно поддерживать.
    Сложнее, чем С.
    И потом, базовые библиотеки должны быть с сишным интерфейсом - С++ классы не очень-то подергаешь из других языков.

     
     
  • 4.18, Coder (?), 00:27, 17/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Если руки из плечей растут, то классы можно дергать из любых языков, а уж из плюсов в особенности это легко делать
     
  • 3.16, Sw00p aka Jerom (?), 22:39, 16/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    >>>>>по переписыванию библиотеки shell32 с языка C на C++
    >>>дальше читать не стал
    >  всетаки ооп в плане написания большого объема кода гараздо удобнее и
    > правельнее. но это не в коем случае не камень в огород
    > сей.

    А что легче отладить ООП-ешный код или процедурный ?

     
     
  • 4.17, Аноним (-), 22:56, 16/10/2011 [^] [^^] [^^^] [ответить]  
  • +2 +/
    >А что легче отладить ООП-ешный код или процедурный ?

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

     
     
  • 5.22, Sw00p aka Jerom (?), 11:36, 18/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    +1
    ну ващето безразницы что за язык - главное иметь скилы дизассемблинга
     
  • 4.19, arisu (ok), 13:25, 17/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
    > А что легче отладить ООП-ешный код или процедурный ?

    легче отладить *хороший* код. а остальное — незначительные мелочи.

     

  • 1.14, robux (ok), 12:17, 16/10/2011 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    USB уже работает?
    Нет?! в БиоReactor! :)
     
     
  • 2.20, Уже зарегистрирован (?), 14:43, 17/10/2011 [^] [^^] [^^^] [ответить]  
  • +/
      Нет предела совершенству, а пока система допилена до уровня Wine, пусть хоть поддержку(поддержку установки) необходимых драйверов на минимальном уровне сделают USB 2.0, sata, video-drivers(и другое, хотя бы 1024х768) video, сеть, чтоб запускать на реальном железе.
      А то ведь для запуска на qemu мне теперь надо процессор менять, мой не поддерживает аппаратно виртуализацию.
    Делают сначала поддержку всяких изощренных вирусов а потом железа. Зачем?
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру