Как работает Wine
Wine — это свободное программное обеспечение для запуска Windows-приложений на нескольких POSIX-совместимых операционных системах, включая Linux, macOS и BSD.
Если вы любите Linux, то наверняка когда-то запускали Wine. Возможно, для какой-то «важной» программы Windows, у которой нет аналога под Линуксом, или поиграться. Забавный факт: даже Steam Deck от Valve запускает игры через оболочку на основе Wine (она называется Proton).
За последний год я намучился с отладчиком, который позволяет одновременно дебажить и Wine, и Windows-приложение в нём. Разобраться во кишочках Wine оказалось очень интересно! Я-то раньше много им пользовался, но никогда не понимал механику целиком. Можно взять файл Windows — и просто запустить его в Linux без каких-либо изменений. Если вы хотите знать, как это сделано, добро пожаловать под кат.
Дисклеймер. В статье реальность сильно упрощается, а многие детали игнорируются. Текст даёт общее представление, как работает Wine.
© «Время приключений» (1 сезон, 18 серия) — прим. пер.
Wine — не эмулятор!
Прежде чем разбираться в работе Wine, нужно сказать, чем он НЕ является. Вообще, W.I.N.E. — это рекурсивный акроним, который расшифровывается как «Wine Is Not an Emulator». Почему? Потому что есть куча отличных эмуляторов и для старых архитектур, и для современных консолей, а Wine принципиально реализован по-другому. Давайте вкратце рассмотрим, как вообще работают эмуляторы.
Представьте простую игровую приставку, которая понимает две инструкции:
- push <value> — пушит заданное значение в стек
- setpxl — достаёт три значения из стека и рисует пиксель с цветом arg1 в точке (arg2, arg3)
Бинарный файл игры (или картридж ROM) представляет собой последовательность таких инструкций, которые аппаратное обеспечение может загрузить в память и выполнить. Нативное железо выполняет их в натуральном режиме, но как запустить старый картридж на современном ноуте? Для этого делаем эмулятор — программу, которая загружает ROM из картриджа в оперативную память и выполняет его инструкции. Это интерпретатор или виртуальная машина, если хотите. Реализация эмулятора для нашей приставки с двумя инструкциями будет довольно простой:
Настоящие эмуляторы намного сложнее, но основная идея та же: поддерживать некоторый контекст (память, регистры и т.д.), обрабатывать ввод (клавиатура/мышь) и вывод (например, рисование в каком-то окне), разбирать входные данные (ROM) и выполнять инструкции одну за другой.
Разработчики Wine могли пойти по этому пути. Но есть две причины, почему они так не поступили. Во-первых, эмуляторы и виртуальные машины тормозные по своей сути — там огромный оверхед на программное выполнение каждой инструкции. Это нормально для старого железа, но не для современных программ (тем более видеоигр, которые требовательны к производительности). Во-вторых, в этом нет необходимости! Linux/macOS вполне способны запускать двоичные файлы Windows нативно, их нужно только немного подтолкнуть…
Давайте скомпилируем простую программу для Linux и Windows и сравним результат:
Слева — Linux, справа — Windows
Результаты заметно отличаются, но набор инструкций фактически один и тот же: push , pop , mov , add , sub , imul , ret .
Если бы у нас был «эмулятор», который понимает эти инструкции, то смог бы выполнить обе программы. И такой «эмулятор» существует — это наш CPU.
Как Linux запускает бинарники
Прежде чем запускать чужеродный двоичный файл, давайте разберёмся, как запускается под Linux родной бинарник.
Довольно просто, но давайте копнём глубже. Если сделать .app ?
Самое главное, что .app — это динамически исполняемый файл. Он зависит от некоторых динамических библиотек и требует их присутствия в рантайме. Иначе не запустится. Другой интересный момент — запрос интерпретатора ( requesting program interpreter в последней строке листинга). Какой ещё интерпретатор? Я думал, что C++ — компилируемый язык, в отличие от Python…
В данном контексте интерпретатор — это «динамический загрузчик». Специальный инструмент, которая запускает исходную программу: разрешает и загружает её зависимости, а затем передаёт ей управление.
При запуске исполняемого файла ядро Linux определяет, что файл динамический и требует загрузчика. Затем оно запускает загрузчик, который выполняет всю работу. Это можно проверить, если запустить программу под отладчиком:
Мы видим, что первая выполненная инструкция находится в библиотеке ld-2.33.so , а не в бинарнике .app .
Подводя итог, запуска динамически связанного исполняемого файла в Linux выглядит примерно так:
- Ядро загружает образ (≈ двоичный файл) и видит, что это динамический исполняемый файл
- Ядро загружает динамический загрузчик ( ld.so ) и передаёт ему управление
- Динамический загрузчик разрешает зависимости и загружает их
- Динамический загрузчик возвращает управление исходному двоичному файлу
- Оригинальный двоичный файл начинает выполнение в _start() и в конечном итоге доходит до main()
Однако если пропустить шаги с первого по четвёртый и каким-то образом перескочить на пятый, то теоретически должно сработать, верно? Ведь с точки зрения операционной системы что значит «запустить» бинарный файл?
В каждом исполняемом файле есть раздел .text со списком сериализованных инструкций CPU:
Чтобы «запустить» бинарный файл, ОС загружает его в память (в частности, раздел .text ), устанавливает указатель текущей инструкции на адрес, где находится код, и всё — исполняемый файл типа «запущен». Как сделать это для исполняемых файлов Windows?
Легко! Просто возьмём код из исполняемого файла Windows, загрузим в память, направим %rip в нужное место — и CPU с радостью выполнит этот код! Если архитектура процессора одинаковая, то процессору вообще без разницы, откуда выполнять ассемблерные инструкции.
Hello, Wine!
По сути, Wine — это «динамический загрузчик» для исполняемых файлов Windows. Это родной двоичный файл Linux, поэтому может нормально запускаться, и он знает, как работать с EXE и DLL. То есть своего рода эквивалент ld-linux-x86-64.so.2 :
Здесь wine64 загружает исполняемый файл Windows в память, анализирует его, выясняет зависимости, определяет, где находится исполняемый код (т. е. раздел .text ), и переходит в этот код.
На данный момент наша Linux-система выполняет код, изначально скомпилированный для Windows, и всё вроде бы работает. За исключением системных вызовов.
Системные вызовы
Системные вызовы (syscall) — вот где основные сложности. Это вызовы к функциям, которая реализованы не в бинарнике или динамических библиотеках, а в родной ОС. Набор системных вызовов представляет системный API операционной системы. В нашем случае это Windows API.
Примеры системных вызовов в Linux: read , write , open , brk , getpid
Примеры в Windows: NtReadFile , NtCreateProcess , NtCreateMutant ��
Системные вызовы не являются обычными вызовами функций в коде. Открытие файла, например, должно выполняться самим ядром, поскольку именно оно следит за файловыми дескрипторами. Поэтому приложению нужен способ как бы «прервать своё выполнение» и передать управление ядру (эта операция обычно называется переключением контекста).
Набор системных функций и способы их вызова в каждой ОС разные. Например, в Linux для вызова функции read() наш бинарник записывает в регистр %rdi дескриптор файла, в регистр %rsi — указатель буфера, а в %rdx — количество байт для чтения. Однако в ядре Windows нет функции read() ! Ни один из аргументов не имеет там смысла. Бинарник Windows использует свой способ выполнения системных вызовов, который не сработает в Linux. Не будем здесь углубляться детали системных вызовов, например, вот отличная статья о реализации в Linux.
Скомпилируем ещё одну небольшую программу и сравним сгенерированный код в Linux и Windows:
Слева — Linux, справа — Windows
На этот раз мы вызываем функцию из стандартной библиотеки, которая в конечном итоге выполняет системный вызов. На скриншоте выше версия Linux вызывает puts , а версия Windows — printf . Эти функции из стандартных библиотек ( libc.so в Linux, ucrtbase.dll в Windows) для упрощения взаимодействия с ядром. Под Linux сейчас частенько собирают статически связанные бинарники, не зависимые от динамических библиотек. В этом случае реализация puts встроена в двоичный файл, так что libc.so не задействуется в рантайме.
Под Windows до недавнего времени «системные вызовы bcgjkmpjdfkb только вредоносные программы» [нет источника] (вероятно, это шутка автора — прим. пер.). Обычные приложения всегда зависят от kernel32.dll/kernelbase.dll/ntdll.dll , где скрывается низкоуровневая магия тайного общения с ядром. Приложение просто вызывает функцию, а библиотеки заботятся об остальном:
источник
В этом месте вы наверное поняли, что будет дальше. ��
Трансляция системных вызовов в рантайме
А что, если «перехватывать» системные вызовы во время выполнения программы? Например, когда приложение вызывает NtWriteFile() , мы берём управление на себя, вызываем write() , а потом возвращаем результат в ожидаемом формате — и возвращаем управление. Должно сработать. Быстрое решение в лоб для примера выше:
По идее, можно сделать собственную версию ucrtbase.dll со специальной реализацией printf . Вместо обращения к ядру Windows она будет следовать формату интерфейсов Linux ABI и вызывать функцию write из библиотеки libc.so . Однако на практике мы не можем изменять код этой библиотеки по ряду причин — это муторно и сложно, нарушает DRM, приложение может статически ссылаться на ucrtbase.dll и т. д.
Поэтому вместо редактирования бинарника мы внедримся в промежуток между исполняемым файлом и ядром, а именно в ntdll.dll . Это «ворота» в ядро, и Wine действительно предоставляет собственную реализацию. В последних версиях Wine решение состоит из двух частей: ntdll.dll (библиотека PE) и ntdll.so (библиотека ELF). Первая часть — это тоненькая прокладка, которая просто перенаправляет вызовы в ELF-аналог. А уже он содержит специальную функцию __wine_syscall_dispatcher , которая выполняет магию преобразования текущего стека из Windows в Linux и обратно.
Поэтому в Wine системный вызов выглядит следующим образом:
Диспетчер системных вызовов — это мост между мирами Windows и Linux. Он заботится о соглашениях и стандартах для системных вызовов: выделяет пространство стека, перемещает регистры и т. д. Когда выполнение переходит к библиотеке Linux ( ntdll.so ), мы можем свободно использовать любые нормальные интерфейсы Linux (например, libc или syscall ), реально читать/записывать файлы, занимать/отпускать мьютексы и так далее.
И это всё?
Звучит почти слишком просто. Но так и есть. Во-первых, под Windows много разных API. Они плохо документированы и имеют известные (и неизвестные, ха-ха) ошибки, которые следует воспроизвести в точности. (Вспомните, как при разработке Windows 95 туда скопировали утечку памяти из SimCity, чтобы популярная игра не крашилась в новой ОС. Возможно, такие специфические вещи приходится воспроизводить под Linux для корректной работы конкретных программ — прим. пер.). Большая часть исходного кода Wine — это реализация различных Windows DLL.
Во-вторых, системные вызовы можно выполнять по-разному. Технически ничто не мешает Windows-приложению выполнить прямой системный вызов через syscall , и в идеале это тоже должно работать (как мы уже говорили, Windows-игры делают всякие безумные вещи). В ядре Linux специальный механизм для обработки таких ситуаций, который, конечно, добавляет сложности.
В-третьих, весь этот бардак 32 vs 64 бит. Есть много старых 32-битных игр, которые никогда не перепишут на 64 бита. В Wine есть поддержка обеих платформ. И это тоже плюс к общей сложности.
В-четвертых, мы даже не упомянули wine-server — отдельный процесс Wine, который поддерживает «состояние» ядра (открытые дескрипторы файлов, мьютексы и т. д.).
И последнее… о, так вы хотите запустить игру? А не просто hello world? Ну так это совсем другое дело! Тогда нужно разобраться с DirectX, со звуком (привет, PulseAudio, старый друг), устройствами ввода (геймпады, джойстики) и т. д. Куча работы!
Wine разрабатывался в течение многих лет и прошёл долгий путь. Сегодня вы без проблем запускаете под Linux самые последние игры, такие как Cyberpunk 2077 или Elden Ring. Чёрт возьми, иногда производительность Wine даже выше, чем у Windows! В какое замечательное время мы живём…
P. S. На всякий случай повторим дисклеймер: статья даёт только базовое представление о работе Wine. Многие детали упрощены или опущены. Так что не судите очень строго, пожалуйста.
What is Wine?
Wine (originally an acronym for «Wine Is Not an Emulator») is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, & BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop.
Wine в Linux
И Windows, и Linux имеют свои собственные API, но поскольку эти две операционные системы сильно отличаются между собой, их API не могут взаимодействовать друг с другом. Это означает, что приложения Windows не могут работать в Linux, по крайней мере, без слоя совместимости. И это именно то, чем является Wine… слой совместимости.
Что такое Wine?
Wine (акроним «Wine Is Not an Emulator») — это слой совместимости, который упрощает запуск нужных вам Windows-приложений в Linux-системах. Wine не эмулирует Windows.
Чтобы начать пользоваться Wine, сначала вы должны установить его на свой компьютер с Linux. После этого, при помощи терминала и соответствующих команд вы можете скачать нужные вам приложения Windows. Если рассматриваемое приложение поддерживается Wine, то у вас не должно возникнуть проблем с его запуском.
При наличии Wine вызов API Windows-приложения на лету преобразуется в соответствующий вызов Linux API. Конечно, речь идет не только об API. Для правильной работы Windows-приложения в значительной степени полагаются на файлы динамически подключаемых библиотек (сокр. «DLL» от «Dynamic Link Library»). К счастью, Wine предоставляет свои собственные версии различных DLL-файлов Windows.
Единственное, чего не может сделать Wine, — это напрямую обратиться к ядру Windows. В таких случаях Wine передает соответствующий вызов ядру Linux. Если программе нужно сделать что-то, чего не может ядро Linux, Wine преобразует вызов во что-то, с чем может работать Linux.
Какие Windows-приложения поддерживаются Wine?
В настоящее время существует большое количество Windows-приложений, которые полностью поддерживаются Wine и работающие на нем без каких-либо проблем. Тем не менее, каждый день появляются все новые приложения для Windows. Многие из них не будут работать в связке с Wine так, как этого хотелось бы. Но стоит отметить, что темпы развития Wine довольно стремительны, постоянно добавляется поддержка новых приложений. Отслеживать изменения можно с помощью базы данных совместимых приложений.
База данных приложений Wine насчитывает почти 24 000 программ различного статуса совместимости (или скорее даже рейтинга) в зависимости от того, насколько хорошо эти приложения работают в Wine. Вот значения этих рейтингов:
Platinum — данные приложения устанавливаются и безупречно работают в стандартном Wine.
Gold — данные приложения работают с некоторой дополнительной конфигурацией Wine.
Silver — приложения с незначительными проблемами.
Bronze — есть серьезные проблемы, которые влияют на использование.
Garbage — приложения, которые просто не будут работать в Wine.
Для поиска приложений в базе Wine на официальном сайте используется пункт меню Browse Apps (слева на боковой панели):
Также в этом разделе доступна и другая информация, а именно: обзоры программ, процедуры установки, с какой версией Wine программа была протестирована, а также различные полезные данные для каждого приложения.
Конечно, база данных приложений Wine в основном состоит из пользовательских данных, но вы всегда можете попробовать запустить приложение с другой версией Wine и поделиться своим результатом с остальным сообществом.
Установка Wine
Установка Wine не является сложной задачей. Мы рассмотрим установку Wine в Ubuntu, Debian и Fedora.
Установка Wine в Ubuntu
Примечание: В примере используется Ubuntu Desktop 21.10.
Шаг №1: Откройте терминал и установите Wine с помощью следующей команды:
sudo apt install wine -y
Примечание: Вы можете получить сообщение об ошибке типа: «Package ‘wine’ has no installation candidate». В этом случае попробуйте использовать следующую команду:
sudo apt-get install wine-stable -y
Чтобы установить самую свежую версию Wine, введите команду:
sudo apt install wine-development -y
Шаг №2: При появлении запроса введите свой пароль.
Шаг №3: Дождитесь окончания установки (Wine имеет большое количество зависимостей).
Готово! Теперь Wine готов к работе!
Установка Wine в Debian
Установка Wine в Debian Linux очень похожа на установку в Ubuntu, но с одним небольшим отличием. По умолчанию в Linux устанавливаются пакеты только той архитектуры (разрядности), которая соответствует архитектуре центрального процессора (на данный момент, это почти всегда 64 бита). Ubuntu, вне зависимости от разрядности ОС, автоматически устанавливает все необходимые библиотеки Wine (как 32-битные, так и 64-битные). А вот в 64-битном Debian для установки 32-битных пакетов Wine необходимо вручную активировать поддержку соответствующей архитектуры (i386):
sudo dpkg —add-architecture i386
Установка Wine в Debian Linux очень похожа на установку в Ubuntu. Для этого введите следующие команды:
sudo apt install wine wine32
Установка Wine в Fedora
Примечание: В примере используется Fedora 35.
Для установки Wine в Fedora выполните следующую команду:
sudo dnf install wine
Настройка Wine
Следующим шагом нужно будет убедиться, что окружение Wine настроено должным образом. Нас интересует наличие каталога (он создается по умолчанию), который будет «обманывать» установщики программ, заставляя их думать, что приложения установлены в стандартном каталоге Windows.
Шаг №1: Введите в терминале следующую команду:
Примечание: Если перед этим моментом вы не установили Wine, то ваша Linux-система может попросить вас установить дополнительное ПО (а именно, зависимости).
Шаг №2: Когда откроется окно настроек winecfg, перейдите на вкладку Диски и убедитесь, что у вас в диске C: указан путь ../drive_c :
Шаг №3: Оставьте оба окна (терминал и «Настройка Wine») открытыми.
Установка Windows-приложений с помощью Wine
Установку Windows-приложений можно произвести из командной строки. Но сначала нужно убедиться, что у Wine есть вся необходимая информация об устанавливаемом ПО.
Примечание: В качестве примера мы установим программу Notepad++.
Для этого скачайте установочный файл Notepad++. Затем в окне настроек Wine перейдите на вкладку «Приложения» и нажмите кнопку «Добавить приложение…» :
Щелкните стрелку раскрывающегося списка пункта «Искать в» > выберите свое имя пользователя > «Downloads» :
Выберите файл установки Notepad++ (в моем случае это npp.8.1.9.2.Installer.exe) и нажмите «Открыть» :
Затем в раскрывающемся списке «Версия Windows» выберите пункт «Использовать по умолчанию» и нажмите «ОК» :
Теперь перейдем к непосредственной установке программы Notepad++.
Откройте терминал и перейдите в каталог Загрузки (или Downloads):
Выполните установку Notepad++:
Выберите язык и нажмите «OK» :
Затем нажмите кнопку «Далее >» :
Примите лицензионное соглашение:
Еще раз нажмите кнопку «Далее >» :
Затем поставьте галочки возле тех компонентов, которые вам нужны. Если не знаете, что выбрать, то просто нажмите кнопку «Далее >» :
Нажмите кнопку «Установить» :
Дождитесь окончания установки и нажмите кнопку «Готово» :
После этого откроется окно программы Notepad++:
Поздравляю вас! Вы только что установили с помощью Wine свое первое Windows-приложение в Linux.
Запуск приложений в Wine
Вместе с Wine устанавливается Файловый менеджер Wine. С его помощью вы можете перейти в каталог, в котором находится установленное приложение, и запустить его. Для этого введите в терминале следующую команду:
Затем перейдите в каталог C:\Program Files\Notepad++ и дважды щелкните по notepad++.exe:
Теперь вы можете использовать приложение!
Когда вы закончите использовать приложение, закройте его как обычно. Когда оно вам снова понадобится, откройте Файловый менеджер Wine и запустите его.
Альтернативные способы установки приложений с помощью Wine
Возможно, вы заметили, что в базе данных приложений Wine при просмотре каждой версии приложения упоминается конкретная версия Wine. Это происходит из-за быстрых темпов развития Wine. Приложение, отлично работающее с текущей версией Wine, может не работать с будущей версией из-за внесенных изменений.
Кроме того, я уже упоминал, что ручная установка приложений из окна терминала отнимает много времени, утомительна и порой сбивает с толку. В качестве решения могут применяться другие «дочерние» Wine программы.
PlayOnLinux
PlayOnLinux — полностью основан на Wine. Обеспечивает более простой способ установки и управления приложениями с помощью Wine. PlayOnLinux является бесплатным. Он также доступен для macOS (как PlayOnMac).
Установка PlayOnLinux в Debian 11 выполняется следующим образом:
sudo apt install playonlinux
Вы можете легко выполнять все связанные с Wine задачи при помощи красивого и интуитивно понятного графического интерфейса PlayOnLinux:
Установка и удаление приложений.
Поддержка различных архитектур и версий Wine.
Создание ярлыков для установленных приложений и их запуск.
Lutris
Lutris — это менеджер библиотеки игр для Linux, который позволяет автоматически устанавливать Windows-игры на Linux, используя последние версии Wine (в том числе специально адаптированные для определенных игр). С помощью Lutris вы сможете устанавливать Windows-игры в Linux почти так же легко, как и в Windows, без необходимости что-либо настраивать, не беспокоясь о том, что они будут конфликтовать друг с другом.
Crossover
Crossover — разработан компанией CodeWeavers. Фактически это тот же самый Wine, но с несколькими изменениями и фирменными дополнениями. Также в CodeWeavers работает большая часть разработчиков Wine. В отличие от частых выпусков Wine, релизы Crossover более стабильны, но стоит учесть, что Crossover является платным продуктом.
Удаление Wine
Рассмотрим удаление Wine в системах Ubuntu, Debian и Fedora.
Удаление Wine в Ubuntu
Чтобы удалить Wine в Ubuntu, достаточно ввести следующую команду:
sudo apt purge wine
Удаление Wine в Debian
Та же самая команда, что и для Ubuntu. Только еще добавляется пакет wine32, который мы установили ранее:
Introduction to wine
Wine is a compatibility layer capable of running Windows applications on several POSIX-compliant operating systems, such as Linux, macOS, and BSD. Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop (desktop shortcuts, menu entries, and open-with entries).
Wine recently added support for ChromeOS, and Android.
WineD3D
WineD3D is a compatibility layer capable of running Direct3d from version 1 to version 11 by translating Direct3d calls to OpenGL calls on-the-fly. WineD3D is a part of Wine.
Direct3D is a graphics application programming interface (API) for Microsoft Windows. Part of DirectX, Direct3D is used to render 3D graphics in applications where performance is important, such as games.
Wine developers have been working on adding Vulkan support to WineD3D, but it is not ready yet. DXVK can do that job right now, but it is not a part of Wine.
DXVK is a Vulkan-based translation layer for Direct3D 9/10/11 which allows running 3D applications on Linux using Wine. DXVK is not a part of Wine, it is a separated project founded by Philip Rebohle, and later Joshua Ashton joined him to offer support for Direct3D 9 which was not supported before by DXVK, and they are both are hired by Valve to work on Proton.
VKD3D
VKD3D is a Vulkan’s based translation layer for Direct3D 12 which is used by default on WINE, and Proton. It is founded by Józef Kucia, WINE developer, who passed away in 2019 at the young age of 30 in an accident, then the development continued by Hans-Kristian Arntzen on a separate project by the name VKD3D-Proton, and he is joined by Valve developers, Philip Rebohle and Joshua Ashton.
Wine Gecko
Wine implements its own version of Internet Explorer. The implementation is based on a custom version of Mozilla’s Gecko Layout Engine.
After you run Wine for the first time, it will prompt you to download, and install the 32bit, and the 64bit of Wine Gecko if it is not intalled in the current wineprefix. Downloaded files can be found in this directory »
More information can be found in this link » https://wiki.winehq.org/Gecko
Wine Mono
Mono is an open-source and cross-platform implementation of the .NET Framework. Wine can use a Windows build of Mono to run .NET applications.
After you run Wine for the first time, it will prompt you to download, and install Wine Mono if it is not intalled in the current wineprefix. Downloaded files can be found in this directory »
Microsoft .NET
If you need to use Microsoft’s implementation of the .NET framework, the Microsoft runtimes can partly run on Wine.
You can install the appropriate version of Microsoft’s .NET runtime (dotnet11, dotnet20, dotnet30, dotnet35, dotnet40, dotnet45, dotnet46, dotnet47, or dotnet4.8) through winetricks.
More information can be found in this link » https://wiki.winehq.org/Mono
FAudio
FAudio is an XAudio reimplementation that focuses solely on developing fully accurate DirectX Audio runtime libraries for the FNA project, including XAudio2, X3DAudio, XAPO, and XACT3.
FAudio became a part of Wine since Wine version 5.0, and when you install Wine 5.0, FAudio will be installed as a dependency to Wine. FAudio is a part of Proton as well, and it fixes a lot of sound issues that could only be fixed before by install Xact through winetricks. The project is founded by Ethan Lee.
Nvidia PhysX
PhysX is a physics simulation library provided by NVIDIA which is used in some games. Wine supports this library since quite some time in the CPU fallback mode which means that all physic calculations are done on your CPU. On Windows PhysX also supports offloading of calculations to NVIDIA based graphic cards through CUDA. Starting with Wine Staging 1.7.34 the necessary features were added to provide the same possibility in Wine.
To use PhysX, you need first to install the PhysX software into the wineprefix containing the program requiring PhysX support.
You can verify that PhsysX is working properly using the PhysX FluidMark Benchmark. The software displays in the start dialog whether GPU acceleration is available. You can also compare the FPS between GPU and CPU based simulations by changing the GPU checkbox in the start dialog.
What is wineprefix
Wine uses a virtual C: drive instead of your real C: drive. The directory in which this is located is called a wineprefix.
Wine creates a wineprefix inside
/.wine after you run Wine for the first time, and Wine updates that wineprefix everytime a new Wine release is installed.
You can change the default location of Wine prefix using WINEPREFIX environment variable which will be explained in details later
- Any file or folder precede by a dot is hidden, and you need to show hidden files using your File Manager to show these files.
- This symbol »
The contents of wineprefix
system.reg , user.reg , and userdef.reg are used to store registry settings.
dosdevices contains symlinks (shortcuts) to the mounted drives on your system
c: points to the other folder inside Wine prefix » drive_c
z: points to the root directory / that you used during the installation of your Linux distro.
The other letters are reserved to other drives that your Linux system may mount later like: external hard drives, USB flash drives, and ISO images mounted on your system. Wine does not assign letters to the mounted drives inside your main hard-disk, but you can do that using winecfg if you want.
drive_c contains the same folders that you can found under the C drive on any Windows operating system
Program Files is used for installed 64bit applications. The path for this folder on Windows is:
Program Files (x86) is used for 32bit applications. The path for this folder on Windows is:
C:\Program Files (x86)
ProgramData is used for application data. The path for this folder on Windows is:
users contains 2 directories: Public and another directory with the user name you used when installing your Linux distro.