ARWINSS

Материал из Русский WINE
Перейти к: навигация, поиск

Что такое ARWINSS?

ARWINSS (Another Realization of WIN32 SubSystem) представляет собой альтернативную реализацию подсистемы win32, предназначенную для упрощенного переноса WINE на платформы, отличные от unix. Ключевое изменение - переработка архитектуры в сторону модульности. В первую очередь, речь идет о "подменяемости" графического вывода.


В настоящее время в Wine использует промежуточный "слой совместимости" с графической подсистемой конкретной платформы, на которой он работает. В linux/*nix этот слой представляет собой "драйвер" winex11.drv, перенаправляющий графический вывод Wine на X Windows System. В ARWINSS, удалось сделать замену этому "драйверу", под названием winent.drv, использующую графические возможности соответствующей ему части ядра ReactOS/Windows, и получив фактически работающие в ReactOS библиотеки user32 и gdi32 из Wine.


Так как код user32/gdi32 в Wine является протестированным и относительно надёжным, предполагается, что ARWINSS обеспечит большую совместимость с приложениями, чем нынешняя реализация win32 в ReactOS, содержащая "кашу" из разных версий Wine с вкраплениями собственного кода ReactOS той или иной степени актуальности. Кроме того, ARWINSS позволит обмениваться с проектом Wine гораздо большим количеством кода, а также использовать "дешевые" (не требующие значительного времени разработчиков) синхронизации с Wine библиотек user32 и gdi32.


Таким образом, ARWINSS должна (по крайней мере, теоретически) обеспечить работоспособность в ReactOS как минимум всех тех программ, которые работают в последних версиях Wine.


Перевод обращения к разработчикам в списке рассылки ros-dev reactos org, (предлагающее переход на новую Win32 подсистему для существенного ускорения разработки и возможности реально использовать ReactOS.)

Сегодня я хотел бы официально представить (под)проект, над которым я работал в течение последнего полугодия и пригласить поучаствовать остальных разработчиков.

ReactOS существует уже около 11 лет, и каждый год становится лучше и лучше. Потребонсть в Windows-совместимой операционной системе с открытым исходным кодом велика: серверы, нетбуки, бухгалтерия, кассовое оборудование Point of Sales, САПР… Этот список можно ещё продолжать и продолжать.

Время идёт, выпускаются новые версии операционных систем Windows. Однако, ReactOS все ещё не достигла состояния, в котором его можно было бы реально использовать. Более того, ReactOS даже официально не перешла в бету. По-отдельности, есть много достижений: появилась поддержка звука, загрузчик в состоянии загрузить реальную Windows, в ReactOS могут загружаться и нормально работать некоторые бинарные драйверы Windows, каждый день улучшается работа с сетью, также активно ведутся работы над ядром. Но для конечно пользователя все это не имеет ни малейшего значения! Пользователю важно, чтобы веб-браузер загружал вебсайты, клиент обмена мгновенными сообщениями работал, [Microsoft/Open] Office открывал документы, а клиент электронной почты получал новые сообщения.

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

Частью ReactOS, играющей главную роль в совместимости и реальной используемости, является подсистема Win32. На данный момент, это огромный монстр, требующий намного большего количества человеческих ресурсов, чем мы сейчас имеем. С текущим количеством участвующих разработчиков (и сложности вхождения в процесс разработки этой подсистемы) даже достижение уровня совместимости сравнимого с Windows 2000 является очень сложной и трудоёмкой задачей.

И я придумал то, что может решить эту проблему: Arwinss. Для того, чтобы лучше объяснить, что это такое, я сделал специальную презентацию (URL к слайдам в формате PDF находится в конце этого сообщения). Вам нужно будет представить, что я делаю доклад, используя эти слайды (т.к. реального доклада и видеозаписи я не делал).

Теперь, после того, как Вы посмотрели презентацию, я бы хотел обратится ко всем заинтересованным разработчикам (даже тем, кто до этого не работал над системой ReactOS). Давайте уделим Arwinss некоторое время — неделю, месяц. У каждого человека наверняка найдется несколько часов в неделю, чтобы улучшить что-то в Arwinss. Условия для начала работы довольно простые, некоторые основы изложены в вики (ссылки есть в презентации), и я буду рад проконсультировать по возникающим вопросам.

Если мне почти в одиночку удалось сделать новую подсистему из ничего (на самом деле, используя существующий код Wine и ReactOS) за несколько месяцев, то представьте, что мы сможем сделать вместе?

С уважением,

Алексей Брагин.

Подробное описание:

Критика существующей Win32-подсистемы ReactOS

Основная Win32-подсистема в ReactOS берёт своё начало в 1999 году. Была проделана большая работа по созданию различных её частей, в работе принимали участие многие разработчики Wine. Совместима по системным вызовам win32k.sys, и только местами очень отдалённо напоминает архитектуру Win32-подсистемы Windows XP. Единственная хорошая часть – это графический код в win32k.sys, всё остальное – сочетание старого Wine и собственного кода. Над этой подсистемой работали более 30 человек, большая часть работы – это синхронизация старого кода с Wine’ом. Т.е. фактически пустая работа. Ещё один минус в том, что архитектура Win32-подсистемы в Windows по «красоте» очень далека от совершенства архитектуры ядра NT, и поэтому нет смысла полностью его копировать.

Решение проблемы – Win32-подсистема, версия 2.0.

Возникло естественное желание – сделать лучше, свести затраты на обслуживание на минимум, использовать существующий код по-максимуму. Попытки сделать это предпринимались в ReactOS неоднократно, но все заканчивались полной неудачей. Кроме одной, под названием Arwinss. В её основу легло очень простое решение: Если Wine работает настолько хорошо, и если код Wine всё-равно используется сейчас (но приходится тратить кучу времени на то, чтобы найти куски этого кода, разобраться, синхронизировать этот код с новым Wine, найти то, что от него зависит и ломается, и всё это время потраченное зазря), то почему бы не сделать новую Win32-подсистему именно на основе Wine.

Описание Win32-подсистемы в Windows

Winarc.gif
Картинка и описание с сайта Microsoft:
Как мы видим, подсистема Win32 включает в себя Win32 API, в виде библиотек, таких как KERNEL32.DLL, GDI32.DLL, и USER32.DLL. Интересно отметить, что начиная с Windows NT 4.0, Microsoft переместила часть подсистемы Win32 из пользовательского режима в режим ядра. В частности, драйвер устройства режима ядра Win32k.sys управляет отображением окон, выводом на экран, ввод с клавиатуры и мышки, и передачей сообщений. Он также содержит библиотеку интерфейса графического устройства (GDI.DLL), что используется для отображения графических изображений и текста.


Как все работает в Windows NT. Приведу очень упрощенную картину. Есть ядро и компания. Есть файл win32k.sys который грубо говоря находится в ядре и отвечает за обмен информацией между видеокартой(как видно из описания выше не только видеокартой, но упростим для понимания) через драйвер той же видеокарты с пользовательским режимом. Для чего это нужно? Чтоб информация полученная win32k.sys от видеокарты была через загрузчик библиотек ntdll.dll передана в режим пользователя, где она будет принята подсистемой Win32. То есть информация от видеокарты в конечном итоге надходит к библиотекам (читать файлам) GDI32.DLL, и USER32.DLL, которые отвечают за прорисовку окон и их составляющих а также вывод графических изображений и текста.


Архитектура Arwinss

Arwinss состоит из 4-х модулей: USER32.DLL, GDI32.DLL, Драйвер - WINENT.DRV или WINEX11.DRV, WIN32K.SYS:

  • USER32.DLL - отрисовка окон и т.д.
  • GDI32.DLL - отрисовка графики
  • WINENT.DRV - gdi "драйвер" (переходник)
  • WIN32K.SYS - обрабатывает информацию от видеокарты в режиме ядра

Дополнительно:

  • WIN32CSR.DLL - реализует необходимые части подсистемы CSR наряду с обработкой пользовательского ввода
  • FREETYPE.DLL - нужен GDI32.DLL для рендеринга текста


Модули USER32 и GDI32 представляют собой практически неизменённый код этих же модулей в Wine (изменения касаются лишь только способов вызова Wine сервера, которые в данном случае представляют собой системный вызов в Win32k.sys). WINENT.DRV – это Windows/ReactOS-специфичный user/gdi «драйвер» (драйвер в понятии Wine, не в понятии Windows) для выполнения быстрых операций с графикой и поддержки окон. WINEX11.DRV – это опциональный модуль, в основном использовался для тестирования. Его задача точно такая же, как и в самом Wine.WIN32K.SYS – низкоуровневая поддержка графических операций (с аппаратным ускорением), реализация небольшой части Wine сервера, и минимальная реализация поддержки Win32 для ядра.


620px-Arwinss.png

Таким образом, используя эту подсистему, мы получаем:

  • Лёгкую синхронизацию с новыми версиями Wine (т.е. команда Wine фактически работает на нас, что существенно ускоряет разработку)
  • Более 10 000 программ из appdb.winehq.org становятся поддерживаемыми, плюс все те программы, которые не может запускать сам Wine в силу своих ограничений
  • Хороший исходный код


И оставляем всё худшее в Wine, а именно:

  • Ужасную эмуляцию NT-ядра
  • Неправильные цепочки вызовов в kernel32/ntdll
  • ntoskrnl.exe
  • Очень медленное взаимодействие с Wine-сервером
  • Сам по себе Wine-сервер
  • Связанные с UNIX зависимости

Текущее состояние

Подсистема работоспособна, но есть ряд ошибок, которые специфичны именно для Arwinss. Т.е. их нет в Wine, их нет в ReactOS, но есть в Arwinss. Подсистема основана на уже достаточно старом релизе Wine.

Ссылки

ReactOS
Search.png
Доклады
О ReactOSARWINSSЧеЗа
Информация Новости Выпуски новостейПереводы блоговНовости проектаВидеоReactOS на ХабреUSB от Вадима Галянта
Разработка Руководство по программированиюОтсутствующая функциональностьВетви разработкиКомпоненты системыReactOS и WineПлан работRoadmap ядра by VgalРазработчикиСовместимость с dll WindowsНаиболее значимые изменения за годИспользуемые проектыGoogle Summer of CodeИзвестные проблемы
Порты AMD64ARMXboxPowerPC
Компоненты Файловые системыРежим совместимостиОтчеты об ошибкахПечатьUSBЯдро
Загрузчик Восстановление MBRЗагрузка из GRUBПараметры загрузки
Прочее ARWINSSПриложения в ReactOSОформление ReactOSКоординаторы"Пасхальные яйца"Монетизация
Другое Типы ядерFreeWin95
Помощь
RAM-диск ReactOS по PXEс жесткого диска
Разработка Стиль написания кодаСтандарты RC-файловРабота с документациейВенгерская нотацияGNU Indent • [ Subversion : ветвислияниеиспользование TortoiseSVN ] • Основы переводаОтправка патчей
Репорты Отладка в VirtualBoxОтладка на экранДобавление программы в менеджер приложенийОтправка отчетов
Отладка Com0comGDBKdbgRossym.gdbRoswin.gdbWinDBGРуководство по WinDBGВключение трассировки ядраКоды DPRINTУдалённый отладчик ReactOS
Сборка CMakeRBuildФайлы RBuildАвтоматическое копирование файловСборка MINGW-w64Сборка модулейСреда сборки
Тестирование VirtualBoxVMwareQEMUHyper-VНеобходимый объём дискаПеренос файлов на виртуальный дискУстановка ReactOSУстановка драйверов
Сеть Общие папкиSambaNFS
Игры Установка DirectPlay
Обновление ReactOSЗагрузочная флешкаЧем можно помочь проектуСоздание нового пользователяЗвук и сеть в VirtualBoxСъемка и публикация видеоIRC-каналСторонние компонентыFAQReactOS как рабочая станцияReactOS и UEFI
Обзоры ОболочкаNTVDMWOWCommunity EditionИстория сайтаReactOS ServerКриптографияПО времен XP