Здравствуйте, дорогие друзья! Многие кто давно следит за проектом, наверное помнит, что на официальном сайте ReactOS выходили выпуски новостей. Потом, ~где-то после 2013 года, их выпуск прекратился, а все переводы после переезда сайта на новый движок были удалены.

Но, весь архив переводов новостей сохранился на нашей русскоязычной вики, а новые выпуски, которые выходили начиная с 2021 года мы публиковали в нашем vk-сообществе.

Но теперь новости проекта будут публиковаться и в блоге на Хабре.

И сегодня вам будет представлен перевод 104-го выпуска новостей.


Команда ReactOS приветствует вас! В этом году мы начнем с краткого обзора текущих работ над проектом и расскажем о наших новых разработчиках. Также мы поговорим о текущем состоянии поддержки многопроцессорности (SMP) в ReactOS.

Расширение команды разработчиков

За последнее десятилетие состав команды проекта практически не изменился. Хотя разработка продолжалась, количество новых разработчиков не увеличивалось. Более того, некоторые из ключевых разработчиков стали неактивными, и некоторые из них были ответственны за важные модули ядра проекта.

Это привело к параличу рабочего процесса разработки некоторых компонентов ReactOS, так как никто из команды не имел достаточных навыков для проверки правильности патчей, предоставленных участниками, чтобы включить их в основную ветку. Команда ReactOS в настоящее время применяет следующий подход, чтобы обойти эту проблему: привлекает участников сообщества, которые вносили полезные патчи как минимум в течение года, которые обладают хорошими навыками программирования, сотрудничали с членами команды проекта и готовы работать в интересующей их области.

С учетом сказанного, команда ReactOS рада объявить о вступлении в проект четырех новых разработчиков:

  • Карл Дж. Бялоруцки [Carl J. Bialorucki] (cbialorucki)

  • Дуг Лайонс [Doug Lyons] (Doug-Lyons)

  • Олег Дубинский (oleg-dubinskiy)

  • Уиндмар Сакит [Whindmar Saksit] (whindsaks).

Состояние поддержки многопроцессорности (SMP) и подготовка к GCC 13

Поддержка многопроцессорности для архитектуры AMD64 активно эволюционирует благодаря Тимо Кройцеру (tkreuzer). В частности, он реализовал поддержку замораживания и переключения процессоров (PR #6581), чтобы каждый логический процессор замораживался или переключался правильно. Кроме того, он внедрил базовую поддержку IPIs (межпроцессорных прерываний), необходимых для планирования SMP, отладки и прочего (PR #6130). Эти изменения пока ограничены APC (асинхронными вызовами процедур), DPC (отложенными вызовами процедур) и замораживанием IPIs.

Еще одним важным улучшением для SMP является инициализация ядра в сборке архитектуры AMD64, которая была переработана Тимо (PR #6110). Это позволяет SMP работать корректно.

Blender, работающий в ReactOS 64-бит с 2 ядрами
Blender, работающий в ReactOS 64-бит с 2 ядрами

После предварительных исследований Джексона Брина (jackson2k2) и Симоне Марио Ломбардо (simonelombardo) по компиляции и загрузке ReactOS на GCC 13, Тимо занялся устранением ошибок, чтобы скомпилировать и собрать образ ReactOS в среде сборки GCC 13 (PR #6824). Это необходимый шаг для будущего обновления среды сборки GCC.

Тем временем Джастин Миллер (The_DarkFire) сосредоточен на поддержке SMP для архитектуры x86. Он работал над настройкой загрузки прикладного процессора (PR #5879) в x86 SMP HAL и планирует дальнейшее улучшение x86 SMP. Помимо этого, начались эксперименты по использованию SMP-aware HAL в ReactOS.

Экспериментальная сборка ReactOS 32-бит с SMP
Экспериментальная сборка ReactOS 32-бит с SMP
ReactOS SMP 32-бит, показывающий результаты теста с помощью CPU-Z
ReactOS SMP 32-бит, показывающий результаты теста с помощью CPU-Z

Стоит отметить, что SMP все еще находится в стадии активной разработки, и нет точных оценок, когда поддержка многопроцессорности будет полностью готова, так что следите за обновлениями!

Синхронизация модулей пользовательского режима WINE

Тимо, Джастин и несколько других участников прилагают усилия для обновления некоторых модулей пользовательского режима, заимствованных из WINE. Как вы знаете, ReactOS использует многие компоненты пользовательского режима из WINE. Хотя наша оболочка во многих случаях является исключением из этого правила, основная часть пользовательских библиотек DLL, предоставляющих API для приложений, синхронизирована с проектом WINE в качестве основы.

ReactOS многие годы не обновлял эти компоненты, в то время как WINE продвигался вперед. Обновление этих компонентов значительно улучшает стабильность и функциональность синхронизированных модулей, а также позволяет нам заглянуть в будущее, поскольку все больше возможностей и функций NT6+ интегрируются в проект.

Некоторые ранние эксперименты показали значительное улучшение совместимости приложений на ранних сборках, в которых эти функции включены по умолчанию.

Запуск Python 3.7 в ReactOS (используется для запуска скрипта Winesync)
Запуск Python 3.7 в ReactOS (используется для запуска скрипта Winesync)

Целью этих усилий является внедрение улучшений и исправлений из WINE, которые помогают поддерживать программное обеспечение для API NT6+, которое иначе бы не функционировало. Также работа в данном направлении помогает удалять старые хаки, которые больше не нужны.

Поддержка асинхронного сетевого соединения

ReactOS поддерживает базовые сетевые функции, предоставляемые API Sockets Provider (MSAFD). Этот API требует выполнения сетевых операций синхронно, что имеет много ограничений. В современных приложениях сетевые операции выполняются асинхронно (то есть неблокирующим образом), что в настоящее время не поддерживается ReactOS.

Это приводит к неопределенному поведению и ошибкам с некоторыми сетевыми вызовами API, такими как WSPConnect, которые не работают должным образом при установке сетевого соединения сокета с узлом в асинхронном (неблокирующем) режиме. Таматип Читпонг (Thamatip Chitpong) (TAN-Gaming) намерен решить эту проблему, работая над реализацией поддержки асинхронного сетевого соединения (PR #6349). Во время разработки он также исправил другие случайные ошибки и проблемы, связанные с компонентом MSAFD.

Это значительно улучшает надежность сетевых приложений, таких как веб-браузеры, FTP-клиенты, многопользовательские игры и другие. Хотя производительность пока не соответствует Windows, у Таматипа есть планы на будущее для решения этой и других проблем, которые пока не охвачены его PR.

Улучшения аудио

Недавно Олег Дубинский внес несколько значительных улучшений в аудиоподсистему. В PR #6686 он реализовал поддержку современных аудиоформатов (например,  Extensible audio, Float audio и других). Также он внедрил поддержку высоких частот дискретизации, настройки качества звука по битам на выборку и более двух (стерео) выходных каналов.

Это позволяет многим сторонним программам и играм, включая AIMP 5.30, QMMP 0.12.17, все браузеры на базе Chromium и Game Dev Tycoon, открывать аудиоустройство и проигрывать звуки правильно. Однако звук воспроизводится только тогда, когда минипорт аудиодрайвера (например, Intel AC97, Realtek HD Audio и т.д.) поддерживает запрашиваемый формат напрямую. В противном случае этого не происходит, так как воспроизведение такого формата требует поддержки ресемплинга, которая еще не завершена; поэтому эта функция пока отключена в ReactOS.

Также он добавил поддержку циклического воспроизведения wave (PR #6761). Функциональность циклического воспроизведения позволяет воспроизводить аудиоданные несколько раз (иными словами, воспроизводить их в цикле). Аудиоданные для потоковой передачи содержатся в заголовках wave (каждая их часть находится в своей структуре WAVEHDR).

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

Кроме того, он планирует дальше улучшать аудиостек с новыми исправлениями. Он планирует исправить реализацию DirectSound IKsPropertySet, что позволит таким приложениям, как VirtualDJ 8.2 и Microsoft DirectX Diagnostic Tool, правильно обнаруживать звуковую карту и отображать информацию об аудиоустройстве.

Новый драйвер ATA-накопителей

ReactOS использует драйвер UniATA для поддержки ATA/SATA и различных IDE-контроллеров. Это основа инфраструктуры ATA-устройств в ReactOS, а также единственный открытый драйвер режима ядра Windows/ReactOS для ATA.

Хотя UniATA по-прежнему служит основным модулем для поддержки реализации ATA, он не в идеальном состоянии. Он страдает от ошибок и проблем, которые мешают некоторому оборудованию работать правильно. Исправление этих ошибок требует переписывания больших частей исходного кода UniATA.

Дмитрий Борисов (disean) намерен решить эту проблему, внедрив новый драйвер ATA с поддержкой PnP для устройств PATA и AHCI (PR #6577). Хотя его работа еще не завершена, по ее завершению новый драйвер ATA обеспечит лучшую стабильность системы, а также устранит многие существующие ошибки, присутствующие в драйвере UniATA.

Следите за новыми обновлениями!

С уважением,

Команда ReactOS

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


  1. Deosis
    20.05.2024 03:53
    +6

    У ReactOS нет функции скриншота, раз вам пришлось фотографировать монитор?


    1. maxzh83
      20.05.2024 03:53
      +3

      Это специальный ретрорежим включен просто


    1. Jeditobe
      20.05.2024 03:53
      +4

      Когда постим скрины, из -зала раздаются выкрики, что ReactOS работает только в виртуалке...


      1. Newbilius
        20.05.2024 03:53

        Интересно, что же мешает развернуть виртуалку на весь экран и потом сфоткать?)


  1. spesso
    20.05.2024 03:53
    +11

    Интересно кто будет первым, мелкомягкие выложат исходники 2000-й винды или ReactOS дойдут до релиза?


    1. speshuric
      20.05.2024 03:53
      +1

      Или поглотят как Mono


    1. khajiit
      20.05.2024 03:53

      Сорцы винтукея и хрюши уже утекали же


  1. mikhail_roslov
    20.05.2024 03:53
    +2

    На сегодня кто основные пользователи системы и есть ли статистика по увеличению/уменьшению пользователей?


    1. zolroman
      20.05.2024 03:53
      +3

      судя по статье, у них +4 новых пользователя. даже имена есть)


    1. Jeditobe
      20.05.2024 03:53
      +5

      ~ около 20K скачиваний ежемесячно устаревшего релиза 0.4.14

      https://sourceforge.net/projects/reactos/files/ReactOS/0.4.14/stats/timeline?dates=2023-02-20+to+2024-05-20


      1. mikhail_roslov
        20.05.2024 03:53
        +1

        в конце 21го видимо, что-то интересное из фич завезли, что создало резкий скачек скачиваний в месяц даже больше 30к, но всё-таки интересно какие сценарии использования системы? Сколько не натыкаюсь на статьи про ReactOS создается впечатление, что она создается исключительно для того, чтобы реализовать интерфейсы windows 10-20 летней давности и иметь возможность запускать старое ПО нативно.


        1. Jeditobe
          20.05.2024 03:53
          +1

          это был сам момент релиза версии 0.4.14


      1. spesso
        20.05.2024 03:53
        +1

        Хм, возможно скоро кол-во пользователей ReactOS превысит кол-во пользователей 2000-ной винды.


  1. digtatordigtatorov
    20.05.2024 03:53

    Зачем вообще изобретать велосипед?

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


    1. Jeditobe
      20.05.2024 03:53
      +3

      Велосипед - это как раз-таки варианты линукса. А ReactOS - не Linux и не его вариант. Требования производства как раз имеются - требуется поддерживаемая и обновляемая система способная запускать legacy-железо, для которого есть оригинальное ПО и драйвера только под Win32.


      1. mikhail_roslov
        20.05.2024 03:53
        +1

        Требования производства как раз имеются - требуется поддерживаемая и обновляемая система способная запускать legacy-железо

        Можно пример?

        На первый взгляд виртуализация для этого сценария выглядит наиболее надежным решением


        1. Jeditobe
          20.05.2024 03:53
          +2

          Много на старых ЧПУ и типографских станках не навиртуализируешь


          1. Gryphon88
            20.05.2024 03:53

            Поэтому один из постоянных типов заказов эмбеддеров "выкинь старую электронику и поставь новую, исполнительные механизмы не трогай".


  1. 1MK-Ultra
    20.05.2024 03:53

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


    1. Jeditobe
      20.05.2024 03:53
      +1

      Могут, просто пока еще не все подряд


  1. Konovalovrg
    20.05.2024 03:53

    Наблюдается переход на ARM-ы ... а REACT за которой я уже лет 10 наблюдаю, знает про это?