LinuxやMacでWindows用ソフトを動かすWineとDebian/Ubuntuでの導入

といった(広い意味でのUNIX系の)OS上でWindowsと互換性のある環境を提供し、ビルド済みのWindows用実行ファイルを読み込む機能により、同環境上でWindowsアプリケーションを動かす機能を持つ。自由なソフトウェアで、ライセンスはLGPL(バージョン2.1もしくはそれ以降)。ソースの一部はWindows互換OSとして開発されているReactOSでも共通して使用できるもので、実際に同OSのDLLや付属ソフトウェアにおいて使われている。

macOSについては過去にX11に依存していたが、バージョン1.6系時点ではこれは不要となっており、その後もmacOS関係の改善は続いている。

Windowsのデバイスドライバは基本的に使用できず、特定の外部ハードウェアと密接なプログラムは構造上動かないことがある。

バージョン1.2系時点でx86_64アーキテクチャ上で64bitのWindowsアプリケーションの実行がサポートされており、GNU/Linuxのディストリによってはx86_64版のOSにディストリのパッケージをインストールすることで32bitと64bitのどちらのプログラムも動かせるようになっている(16bitアプリケーションも動作可能)。

動作速度

“Wine Is Not an Emulator” の略ともされているように、WineはCPU命令の変換処理は行わないため、Wineを動かしているハードウェアのCPUアーキテクチャとWindowsアプリケーション側が動作対象としている(Windowsの)アーキテクチャが同一でなければアプリケーションが動かない一方で、Windowsアプリケーション内のCPU処理が同一ハードウェア環境のWindows上と比べて遅くなることはない。ただし、描画APIの関係や他の何らかのバグなどによってWindows上よりも動作速度が低下する場合はある。

IA-32(i386)やx86_64(x64)のアーキテクチャのWindows向けのソフトウェアを他のアーキテクチャ上のOSで動かすにはQEMUによってCPUエミュレーションを別途行う必要がある(動作は遅い)。

仮想Windows環境 (Wine環境・実行環境)

WindowsアプリケーションはWindows環境上で動くものだが、これは

“1つ以上のドライブとその中に存在するディレクトリツリー” というWindows独特のファイルシステムツリー構造
Windows(OS)のシステムドライブのディレクトリツリー
設定データベースである “レジストリ”

から成る。

Wineでは、これらを含んだディレクトリを仮想のWindows環境(アプリケーションの実行環境)として扱い、存在しない場合には自動的に作成される。このディレクトリはWine関係のツールによっては “ボトル” と呼ばれることもある(ワイン瓶に由来)。また、使用・作成されるディレクトリは環境変数WINEPREFIXによって切り替えることもできる。

詳しくは

Wine環境(WINEPREFIX)を分けてWindowsアプリを上手に管理する

を参照。

Wine固有の設定

Wine自体の動作に関する設定項目が多数存在する。一部はwinecfgというコマンドで起動するGUI設定ツールで設定を確認したり変更したりできるが、高度な設定を行う場合にWine用のレジストリ項目を直接作成したり編集したりする必要があるものもある(Winetricksという外部ツールを用いて設定適用する方法もある)。

Wine環境にパッケージを入れたり設定適用したりできるWinetricksとその使い方

ユーザインタフェースにおいて文字化けや文字のレイアウトの問題が見られる場合はまずWinetricksでfakejapanese_ipamonaを試してみるのがよい。

下は設定項目の一部。

フォント名の置換設定
Direct3Dの挙動に関する詳細設定
X11ドライバ用の詳細設定

設定はWine用のレジストリ(HKEY_CURRENT_USER\Software\Wine以下)に保存され、Wineがこれを読み込んで使用する。

実行ファイル名ごとの設定機能

Wine固有の設定項目の一部は実行ファイルの名前ごとに異なる値が設定でき、winecfgでは “アプリケーション” タブで新しい実行ファイルを追加してこれが選択された状態で他のタブで設定を変更する。これにより、特別な設定を行わないと正しく動かないようなプログラムを個別に設定でき、対処が行いやすくなっている。

使用されるレジストリ階層はHKEY_CURRENT_USER\Software\Wine\AppDefaults\Filename.exe(ファイル名部分は実際の名前となる)以下で、これ以下の構造はHKEY_CURRENT_USER\Software\Wine以下と同様。

なお、この機能は実行ファイル名単位なので、他のアプリケーションでも使われるような名前のファイル名の場合はファイル名を変更したりWine環境を分けたりする必要がある。

ネイティブDLLの使用とDLLオーバーライド設定

Wineで実装されているDLL(内蔵版DLL)には一部に未実装機能が残っているなどの問題があり、これにより正しく動作しない機能が存在するが、Microsoftが公開している再頒布可能ランタイムパッケージに含まれるネイティブ版のDLLを代わりに用いることで問題を回避できる場合がある。一方でWindowsのデバイスドライバにアクセスするような一部のDLL(例:d3d9.dll)は構造上ネイティブ版にすることができず、そのようなDLLに不具合がある場合はWineを修正する以外に解決法はない。

ネイティブ版のDLLは仮想Windows環境のシステムフォルダ内に配置するだけでは使用されずにWine内蔵版が使用される仕組みとなっており、別途 “DLLオーバーライド” と呼ばれる機能の設定でネイティブ版を優先するようにする必要がある。

DLLオーバーライドの設定は

対象のDLL名(拡張子は含まない)
DLL読み込みの優先順位の設定

の組み合わせを単位としており、優先順位の設定は

常に内蔵版を使用
常にネイティブ版を使用 (ネイティブ版を使用したい場合にはこれを選択する)
内蔵版があれば使用し、なければネイティブ版を探す
ネイティブ版があれば使用し、なければ内蔵版を探す
無効化・DLLがインストールされていないものとする (特定のDLLが不具合を引き起こしている可能性のあるときなどに使用)

の中から選択する。

設定はGUI設定ツールwinecfgで行うことができ、内容はレジストリに保存されるが、環境変数WINEDLLOVERRIDESを指定してプログラムを実行すると、同環境変数の値による設定がレジストリの値よりも優先されて使用される(一時的に設定を試す際などにおいて有用)。

設定	設定値
常に内蔵版	b
常にネイティブ版	n
内蔵版の後にネイティブ版	b,n
ネイティブ版の後に内蔵版	n,b
無効化	(空文字列)

書式は “[DLL名1],[DLL名2], … =[設定値]” 形式で、 “;” で区切って複数の記述を含めることもできる。

WinetricksをDLL名を指定して実行すると、一部のネイティブ版DLLのダウンロードから配置,DLLオーバーライド設定までを自動で行うことができる他、フォントなどのデータファイルについても同様にダウンロードや配置を簡単に行うことができる。

Wine環境にパッケージを入れたり設定適用したりできるWinetricksとその使い方

DirectX

WineはDirectXを実装しており、基本的には特に追加のインストール作業などを行わずに使用することができる。

描画APIのDirect3DはOpenGLを用いて実装されており、同一ハードウェア環境のWindows上と比べた動作速度はハードウェアやデバイスドライバなどの条件や動かすソフトウェアによっては速くなることもあるとされる。

バージョン1.8系時点ではDirectX 9.0cまでが実装済み。

Direct2DやDirectWriteはバージョン1.8系時点で実装が完了している。

バージョン3.0時点ではDirect3D 11までの実装の大部分が完了しており、2.0.x系と比べて多数の改善が入っている。

Direct3D 12はWineのDirect3D実装の開発者がVulkan APIを用いて開発している “vkd3d” という外部ライブラリ(ライセンスはLGPL-2.1以上)で実装され、バージョン3.xの開発版の途中および4系以上のWineからはこれを通して使用可能になる。このライブラリはUbuntuでは18.10からvkd3d1という名前のパッケージ(Wineなど同ライブラリを用いるプログラムをビルドする際に使用される開発パッケージはvkd3d-dev)でインストール可能になる。

“d3dx[数字]” のDLL群やDirectMusic関係などに実装が不完全な部分があるが、ネイティブ版DLLを使用することで問題が回避できる場合がある。

(2018/2/18)Direct3D 10からDirect3D 12についての記述を追加

(2018/6/16)vkd3d関係の内容を更新

Vulkan APIを用いたDirect3D実装の外部プロジェクト (2018/2/18追記)

Vulkan APIを用いたDirect3D実装の外部プロジェクトとしては以下が確認されている。

DXVK (Direct3D 11とDirect3D 10, zlibスタイルのライセンス, 個人開発だが貢献もある)
DXUP (Direct3D 10, MITライセンス, 個人開発, Direct3D 11でDirect3D 10の機能を実装し、DXVKと一緒に用いるもの)
VK9 (Direct3D 9, zlibスタイルのライセンス, 個人開発)

Vulkan対応GPUを使用している場合はこれらを使用することで速度向上もしくはCPU負荷低減が期待できる。いずれもWindowsのDLL形式で提供され、Wineの3.x系以上の開発版で追加されたVulkanラッパーDLLが必要。64bitOSで32bit用の実装を用いるには(OS側の)Vulkanドライバの32bit版も必要で、Debian/UbuntuでMesaの(自由なソフトウェアの)ドライバを使用している場合はmesa-vulkan-drivers:i386が必要。

(2018/6/16)一部内容を更新

CSMT

WindowsのDirect3Dでは描画処理は描画用のスレッドを設けてそこで行っているが、バージョン1.8系時点のWineではこのような動作にはなっておらず、描画命令順の正確さも保証されないとされる。これにより一部のプログラムでこれが原因の描画不具合が発生したり、同一ハードウェア環境のWindows上と比べて描画処理が遅くなったりすることがある。

Wineでも同様に描画用のスレッドを設けるようにするCSMTという機能の実装に向けた動きが段階的に進んでおり、グラフィックドライバによらずにCPU使用率に余裕があるCPUコアのある環境では描画速度が向上する場合があるのだが、修正の規模が極めて大きく、新しい不具合が発生する原因ともなっているため、後述のWine Stagingで長期間利用可能とはなっているものの、本家に完全に取り込まれるのには時間がかかっている。

(2017/5/13)以下は公式開発版におけるCSMTとその有効化についての追記となる。

バージョン2.6で公式版に搭載されたが、この時点ではテストなどを目的とした一部ユーザ向けという段階で、既定では無効となっており、GUI設定項目もなく、有効にするにはレジストリを編集する必要があった。

この段階で、これまで描画順序の不正確さに起因する描画不具合に対する対処としてのレジストリ設定StrictDrawOrderingを置き換えるものとしては有効なものとなっている。

バージョン2.8時点では、これまで “使用率の低いコアが他にあるにも関わらずグラフィックドライバ内のCPU処理の負荷が1つのコアに集中する(そのコアの使用率が100%に張り付く)” ことにより性能が出し切れていなかった場合において、CSMTを有効にしたときに “余裕のあるCPUコアの使用率が上がると同時に描画性能が上がる” ようになっている。ただ、まだ “性能低下を起こしている部分が幾らか存在し、改善の余地は残っている” とされていた。

バージョン3.2からは初期状態(有効/無効の設定を行っていないとき)で有効となった。フレームレートが十分に出ているゲームなどでは無駄に追加のCPU資源を食うだけになる場合もあるので、描画に問題がなければ省電力のために無効化する手もある。

下はregコマンドによる設定変更例。

(常に有効にする)
$ wine reg add "HKEY_CURRENT_USER\Software\Wine\Direct3D" /v "csmt" /t REG_DWORD /d 1

(Game.exeという実行ファイルに対してのみ有効にする)
$ wine reg add "HKEY_CURRENT_USER\Software\Wine\AppDefaults\Game.exe\Direct3D" /v "csmt" /t REG_DWORD /d 1

強制的に無効化する場合は最後の1を0にして実行し、値を書き換える。

2017年4月下旬以降のWinetricksではcsmt=onを指定して実行することで有効化が、csmt=offで無効化がそれぞれ行える(特定の実行ファイルではなく常に適用される)。

(2018/2/18)バージョン3.2以上についての内容を追加

Gallium Nine (外部プロジェクト)

自由なソフトウェアのグラフィックドライバ使用時にのみWineで利用可能な、外部プロジェクト(Mesaライブラリの一部)によるDirect3D 9のOSネイティブ実装。

OpenGLを経由しない分だけ(処理コスト低下により)CPU使用率が下がったり動作速度が向上したりするが、WineのOpenGLを用いた実装(wined3d)にはない不具合が発生する場合もある。

2016年夏時点では

Wineへの修正が必要かつWine Stagingのパッチにも含まれていない
MesaのパッケージがGallium Nineを有効にしてビルドされておらず、Gallium Nineのライブラリが標準のディストリのパッケージとしてインストールできないディストリが多い

などにより簡単に導入することはできない状況で、UbuntuのPPAは比較的導入が楽だがMesaのバージョンが不安定な開発版になるなどのデメリットもある。

音声の出力

Wineでは、Windowsアプリケーションから出力される音声はOSネイティブのサウンド出力の仕組みを通して出力される。バージョン1.8系時点では(GNU/Linuxで広く使われている)サウンドサーバPulseAudioに対応しており、GNU/Linux上では標準では同サーバへ出力される。

MIDIデバイスについては

WineにおけるMIDIデバイスの扱い

を参照。

ウィンドウと仮想デスクトップ

Wine上で動作するGUIアプリケーションのウィンドウは、(他のネイティブアプリケーションと同様に)これを動かしているOSのウィンドウマネージャで操作できる。ウィンドウの装飾についてはウィンドウマネージャのものを使用するかWindows風の見た目の(“最小化” “最大化” “閉じる” のボタン群のある)装飾を使用することもできる。

画像はWineのウィンドウ装飾を使用したもの。

仮想デスクトップは文字通り仮想のデスクトップ機能を提供するもので、1つの任意のサイズのデスクトップウィンドウを起動してこの中に複数のWindowsアプリケーションのウィンドウを含めることができる。フルスクリーンで動作するプログラムを仮想デスクトップで動かすと、フルスクリーンの解像度のサイズにウィンドウがサイズ変更されてその中でフルスクリーンのプログラムが(ウィンドウ内で)動作する。

仮想デスクトップの更なる機能拡張の動きもある。

外観テーマ

Windows 2000やMe時代までのクラシックな外観テーマ(動作が軽く、色の変更も可能)はもちろん、Windows XP用のテーマをインストールして使うこともできる。また、Wine StagingではGUIツールキットGTK+ 3の外観テーマを使用する機能が提供されており、将来公式でも利用可能になる可能性がある。

付属ソフトウェア

GUIアプリケーションの一部

メモ帳(notepad.exe)
ワードパッド(wordpad.exe)
レジストリエディタ(regedit.exe)
コントロールパネル(control.exe)
OLE/COM オブジェクトビュアー(oleview.exe)
マインスイーパ(winemine.exe)
タスクマネージャ(taskmgr.exe)
Wine ファイルマネージャ(winefile.exe)

端末コマンドの一部

コマンド	説明
cmd	コマンドプロンプトのシェルで多数の内部コマンドを含む
msiexec	MSI形式のパッケージを処理
reg	レジストリ項目を非対話的に読み書きしたり問い合わせたりする
cabarc	Cabinet書庫を扱う
ipconfig	ネットワークインターフェース関係の各種情報を表示
netstat	TCP/IPの接続の状態などを表示

Winelib

Wineが提供するWindows APIの互換機能はライブラリとして使用でき、 “Winelib” (ディストリのパッケージではlibwineなどの名前となる) と呼ばれる。これはWindows用のアプリケーションやプラグインの機能をGNU/LinuxなどのOSで用いるための橋渡しとして使われることもある(例:dssi-vst,wime)。

winegccやwineg++といったGCCのラッパーを使用すると、Winelibを使用してWine上で動作するOSネイティブな実行ファイルをビルドすることができる。リソースファイルはリソースコンパイラwrcでコンパイルする。

上記のコマンド群は追加でWineの開発パッケージをインストールしないと利用できないことが多い。

拡張機能

以下の拡張機能は未インストールの場合にダウンロードするダイアログが表示されて簡単にインストールすることができるが、Debianなどダイアログが無効化されているディストリのパッケージも存在する。

Internet Explorerコンポーネント

WebブラウザInternet Explorerのコンポーネントを用いたWindowsアプリケーションが多く存在するが、Wineにおける同コンポーネントはWebブラウザMozilla Firefoxの一部に基づいた “Wine Gecko” と呼ばれる拡張として存在し、Webページのレンダリング結果やスクリプトの挙動などの動作もMicrosoftのInternet Explorerとは異なる。

Mono/.NETアプリケーション

Mono/.NETアプリケーションを動かすプログラムでクロスプラットフォームかつ自由なソフトウェアMonoをWine向けにビルドした “Wine Mono” と呼ばれる拡張をインストールすることにより、一部のMono/.NETアプリケーションが動作するようになる。

これとは別に、Microsoftによるランタイムパッケージである “Microsoft .NET Framework” をインストールすることで更に他のアプリケーションが動作するようになるが、完全に動作するわけではなく、ライセンスも自由ではない。また、Monoの無効化処理が別途必要となる。

WineでMicrosoft .NET Frameworkを使用する

Wineのバージョン系統

(2016/11/18)バージョン2.0以上では番号の付き方が変更されており、これに伴って以下の内容を新しい情報に変更した。

バージョン2.0以上

系統	バージョン系列	説明
安定版	[メジャーバージョン].0, [メジャーバージョン].0.[リリース(1以上の番号)]	新しい不具合を発生させない範囲の不具合修正(先に開発版系統で適用されたもの)が中心
開発版	[メジャーバージョン].[1以上の番号]	新機能追加と不具合修正の両方が行われるが、新しく不具合が発生することもある

バージョン1.x系まで

系統	バージョン系列
安定版	[メジャーバージョン].[偶数]
開発版	[メジャーバージョン].[奇数]

安定版の最初のバージョンは “[メジャーバージョン].[偶数]” となり、その後 “[メジャーバージョン].[偶数].[リリース(1以上)]” 形式をとっていた。一方、開発版の最初のバージョンは “[メジャーバージョン].[奇数].0” でその後 “[メジャーバージョン].[奇数].[リリース(1以上)]” 形式をとってしばらく開発が続けられた後に次期安定版のリリース候補を経て正式な安定版となり、すぐに次期開発版として開発が続けられていく形だった。

バージョン1.6系までの安定版は多くても2回程度しか更新がされなかったが、1.8系では安定版専用のメンテナが作業を行っており、従来と比較して短めの間隔でリリースを出し続ける形をとった。

Wine Staging

Wine Stagingは、まだ公式版のWineに取り込まれていないパッチを当てたバイナリパッケージを幾つかのディストリのパッケージとして提供することにより

ユーザ側としては新機能や不具合修正を手軽に試すことができる
開発プロジェクト側としてはそのパッチの動作の評価を行いやすく、公式版に取り込まれるまでにかかる手間や期間が短縮され、Wine公式(開発プロジェクト)側としては生産性を向上させるのに役立つ

と、Wineに関わる大部分の人々にメリットをもたらす一方で、パッチが新たな不具合をもたらす可能性も秘めているため、用途によっては不向きなこと(安定版のほうが適する場合)もある。

DebianとUbuntuのパッケージ

Debian/Ubuntuのパッケージ

パッケージ名	説明
wine	本体パッケージだが、中身はWineの基本的なコマンド群を提供するラッパースクリプト群
fonts-wine	フォント (本体からみた推奨パッケージ)
wine32	32bitのWindowsアプリケーションを動かすのに必要なファイル群 (本体から依存)
wine64	64bitのWindowsアプリケーションを動かすのに必要なファイル群 (64bitOSで本体から依存)
libwine	Winelibと各種DLLなどに相当する共有オブジェクトファイル群 (本体から依存)
libwine-dev	Winelibを用いたプログラムをソースからビルドするのに必要なファイル群
wine32-tools	Winelibを用いたプログラムをソースからビルドするのに使用可能なツール群の32bit版 (libwine-devからみた推奨パッケージ)
wine64-tools	Winelibを用いたプログラムをソースからビルドするのに使用可能なツール群の64bit版 (libwine-devからみた推奨パッケージ)
wine-binfmt	binfmt_miscの仕組みで.exeファイルを直接実行したときにWineに渡して動かすようにするファイル

通常はwineパッケージをインストールし、必要に応じてwine-binfmtやlibwine-devを追加インストールする。

開発版系統のWineのパッケージはwine-developmentとこれが依存するパッケージ群から成り、パッケージ名に “-development” を含む以外は上の安定版系統と同様となるが、コマンド名が安定版のものの末尾に “-development” を付けた形のものとなる。

DebianのOSが安定版系統であっても、Wineの安定版,開発版ともに “backports” のリポジトリを登録しておくことで最新バージョンが利用可能となっている。

本家提供のリポジトリで提供されるDebian用パッケージ

Wine公式のDebian用バイナリ配布が行われており、インストール手順などが公式のページに書かれている。Wine StagingのDebian用バイナリはこの手順によって導入できる。

ファイルは開発版が/opt/wine-devel/,Stagingが/opt/wine-staging/以下に配置される。実行するコマンドはこの中のbinディレクトリの中にあり、Stagingのwineコマンドのパス名は/opt/wine-staging/bin/wineとなる。

以前のUbuntu用パッケージ

UbuntuのパッケージはDebianとは別に独自に改善を行ってきている歴史があり、パッケージ名とファイル構成がDebianと大きく異なっているが、~~Debianのパッケージに基づいた形での提供を目指す動きもあり、パッケージ名やファイル構成が今後Debianと同一になる可能性がある。~~また、既にUbuntu 15.10からは開発版系統の “wine-development” パッケージについてはDebianのパッケージに基づいた形で提供されている。

(2016/9/24)Debianのパッケージに基づいたバージョン1.8系のWineがUbuntu 16.10に正式に入り、パッケージ構成もDebianのパッケージに基づいたものとなるが、歴史的な理由によりwineパッケージはメタパッケージとなり、安定版系統の本体パッケージの実体はwine-stableの名前になる。下の表はバージョン1.6系までの古いバージョンのものとなる。

パッケージ名	説明
wine	本体のメタパッケージ
wine[バージョン]	本体やフォント,binfmt_misc関係のファイルなど (メタパッケージから依存)
wine[バージョン]-i386	32bitのWindowsアプリケーションを動かすのに必要なファイル群 (本体から依存)
wine[バージョン]-amd64	64bitのWindowsアプリケーションを動かすのに必要なファイル群 (64bitOSで本体から依存)
wine[バージョン]-dev	Winelibを用いたプログラムをソースからビルドするのに必要なファイル群

本家提供のリポジトリで提供されるUbuntuパッケージ

Debian同様にWineの公式サイトに書かれているリポジトリで提供されるパッケージ。

以前はppa:ubuntu-wine/ppaというPPAリポジトリが使用されており、公式のページにも書かれていたのだが、容量などの関係か、2016年にppa:wine/wine-buildsというリポジトリに移行したが、従来とは異なり、/opt/の下のディレクトリにコマンドがあるため、実行方法には注意が必要。

PPAリポジトリの追加手順(Ubuntuソフトウェアセンター,Synaptic,コマンド)

(2017/4/6)PPAリポジトリからのパッケージ提供はその後非推奨となり、本家のサーバで提供されることになった。

パッケージ名	wineコマンドのパス名	説明
winehq-stable	`/opt/wine-stable/bin/wine`	安定版
winehq-devel	`/opt/wine-devel/bin/wine`	開発版
winehq-staging	`/opt/wine-staging/bin/wine`	Staging版

上記の名前のパッケージはいずれか1つしか選択できない(主に/usr/bin/以下に配置される、/opt/以下に配置される実体に対するシンボリックリンクで構成されるため)が、実体であるwine-stable, wine-devel, wine-stagingの各パッケージは共存が可能。