今回のPC更改*1で悩まされたのが、アクティベーションだった。Windows、Microsoft Office、そしてAdobe Acrobatまで、ことごとく再アクティベーションを要求された。そしてAdobe Acrobatに至っては、Adobeのアクティベーション・サーバー停止に伴い、使用不能に追い込まれてしまった*2。
たとえベンダーがサポートを終了したとはいえ、脆弱性などのセキュリティ・リスクはファイアウォールやセキュリティ・ソフトウェアで対策できるものだし、なによりアプリケーションは問題なく動作し続けているのだ。ベンダーの都合のみによって、不本意な使用停止に追い込まれるのは、納得がいかない。
このようなアプリケーションの対策として挙げられる典型例は、代替となるオープンソース・ソフトウェアを探すことだろう。次いで挙げられるのが、そのようなアプリケーションを、切り出した環境で動作させることだ。具体的には、
- 仮想環境にインストールする。
- OSを超えた、互換レイヤー上で動作させる。
Hyper-Vや、VirtualBoxなどを用いて、アプリケーションが問題なく動作しているOS環境ごと、仮想環境化してしまう。仮想環境はファイル化されるので、同一の仮想環境プラットフォームであれば、OSを問わず機能させることができる。
動作環境ごと仮想化してしまうので、アプリケーションの互換性などを考慮する必要がない。一方、アプリケーション以外のものを動作させるリソースが要求され、それら、アプリケーション以外の処理がオーバーヘッドとなる。
互換レイヤーは、目的とするアプリケーションとの互換性についてのリスクがある一方、そのような間接的なリソース、処理がなくなるため、良好なパフォーマンスが期待できる。
この投稿では、Linux上でWindowsアプリケーションを動作させるための互換レイヤーであるWineと、Windowsアプリケーションをインストールし、動作させるまでの流れを紹介する。
- Wineについて
- Clear Linuxでの導入作業
- 最初の環境構築 - New Machine (wineprefix)の作成
- 日本語フォント
- Windowsアプリケーションのインストール
- 余談
- 参照
Wineについて
Wineは、Windows実行ファイルを呼び出すプログラムと、その処理をLinux環境と仲介するためのライブラリで構成される、互換レイヤーだ。
| プログラム・ローダー | Windows実行ファイルの呼び出し、実行 |
| Winelib | ライブラリ Windows APIとLinux環境の連携 |
仮想環境でもなく、エミュレータでもない、Windowsで言うところの「プログラム互換性アシスタント」「互換モード」に相当する。
そのため、Windowsアプリケーションの動作そのものに付帯する間接的な処理が少なく、それが動作するハードウェアのスペックを直接反映したパフォーマンスを得ることができる。
Wineには想定しているWindows環境（Windows XP, 7, 10など）、それぞれに応じた32bit/64bit環境が用意されている。目的とするWindowsアプリケーションによって、これらを使い分けることになる。
特に32bit全盛期、2000年ごろのWindows動作環境ではDLL Hell*3と呼ばれる、異なるアプリケーション間のライブラリ不整合に起因する問題が多発していた。このような問題を回避するためにも、自ずと動作環境（後述するwineprefix）をコンテナ的に、アプリケーションごとに使い分けることになるだろう。
また、16bitアプリケーションを動作させるには、32bit環境を選択することに注意する必要がある。
| Wine | 動作可能なWindowsアプリケーション |
|---|---|
| 32bit | 16bit 32bit |
| 64bit | 32bit 64bit |
Clear Linuxでの導入作業
Linux環境へのWine導入について、詳細に触れるつもりはないが、Clear Linuxの場合についてだけ、簡単に触れておく。
WineはClear Linuxの公式レポジトリに収録されており、swupdコマンドで導入することができる。具体的には、次のbundleを導入することになる。
- wine
- winegui
- wine-dev
sudo swupd bundle-add wine winegui wine-dev
最初の環境構築 - New Machine (wineprefix)の作成
Wine上で動作するWindows環境のことを、「wineprefix」と呼ぶ。次のように呼ばれることもある。
- bottle
- machine
wineprefixは、wineコマンドから作成することもできるし、GUIを通じて作成することもできる。
注意したいのは、それぞれ異なる場所にwineprefixを作成することだ。一般的に、Wineで作成したwineprefixがデフォルトとなる。Windowsアプリケーションごとにwinprefixを使い分けたい場合など、コマンド実行時に、目的としているwineprefixを指定する必要がある。
Wine、WineGUIの場合では、それぞれ以下の場所に作成される。さらに、wineprefixの配下に仮想的なCドライブ、Windowsフォルダなども生成される。こちらもWine、WinGUIによってパスが異なる。
| Wineの場合 | wineprefix |
~/.wine/ |
|---|---|---|
| Cドライブ |
＄wineprefix/drive_c/ | |
| フォント |
＄wineprefix/drive_c/windows/Fonts/ |
| WineGUIの場合 | wineprefix |
~/.local/share/winegui/prefixes/[Machine Name]/ |
|---|---|---|
| Cドライブ |
＄wineprefix/dosdevices/c:/ | |
| フォント |
＄wineprefix/dosdevices/c:/windows/Fonts/ |
なお、WineGUIでwineprefixを新規作成する場合、Nameに指定した文字列がフォルダ名になる。スペースを含む文字列を指定するのは問題ないが、コマンドでパスを指定する際など、誤りがないよう、注意する必要がある。
 |
 |
日本語フォント
Windowsアプリケーションの文字化け対策
Windowsアプリケーションでも、特に日本語アプリケーションを導入する場合に、ありがちの問題が、いわゆる文字化けだ。
Windowsアプリケーションのインストールに用いるsetup.exeなども、日本語アプリケーションであり、インストール中にも文字化けは発生することがある。そのようなリスクを回避するためにも、Windowsアプリケーションのインストールを始める前に、この問題について対策しておくのが良い。
WineはLinux環境に用意されているフォントを利用する以外に、各wineprefixのフォント・フォルダに格納されたフォントを参照することもできる。このフォルダは、Windows自身のフォント・フォルダに相当する。そのため、文字化け対策として、Windowsの場合と同じ対策が有効に機能する。具体的には、
最も手軽なのは、wineprefix配下のフォント・フォルダへ、必要なフォントをコピーすることだ。Windowsアプリケーションが必要なフォントを参照しているだけならば、これだけで文字化けは解決できる。
Winetricksから代替フォントをインストールし、設定を反映することもできる。
 |
 |
 |
 |
代替フォントについては、ユーザー各自の好みが反映される要素でもあり、試行錯誤を伴うことがある。ユーザーの任意で代替フォントを指定するならば、レジストリを直接編集する必要もある。対象は以下のキーだ。
| Windows標準のキー |
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows NT\CurrentVersion\FontSubstitute |
|---|---|
| Wineの独自キー |
HKEY_CURRENT_USER\Software\Wine\Fonts\Replacements |
 |
 |
Windows UIの文字化け対策
問題はWindows UIの文字化け対策だ。これはフォントを用意するだけでは、解決しない場合がある。Windowsのロケール設定に由来する問題だからだ。そのため、wineprefixの起動コマンドに、ロケールを指定する必要がある。例えば、次のような具合だ。
LANG=ja_JP.UTF-8 wine start [実行ファイルへのパス]
次の画像が示すのは、ロケールを指定するだけで文字化けが解決した事例だ。左の画像はロケール指定なしで起動した状態だ。日本語フォントが反映されている箇所、そうではない箇所がある。反映されていないのは、Windows UIに関連する箇所だ。
右の画像が示すように、同じアプリケーションをロケールを指定して実行するだけで、この問題は解決する。
 |
 |
特にTahomaフォントは、Windowsの標準フォントとして多用されており、ロケールの影響を受けることが多いので注意すること。
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows NT\CurrentVersion\FontSubstitute というキーに MS Shell Dlg という値があり、こちらを変更することでもフォントを設定することができますがこの値は Wine が初期値に書き換えることがあるため変更しても元に戻る可能性があります。例えば LANG=ja_JP.UTF-8 では MS UI Gothic に、LANG=en_US.UTF-8 では Tahoma に戻します。
なお、lsofコマンドを実行して、どのアプリケーション（プロセス）が、どのフォントを参照しているのかを確認することができる。例えば、あるプロセスが参照しているTTF (True Type Font)を確認するには、次のコマンドを実行する。
lsof | grep [プロセス名] | grep ttf
Windowsアプリケーションのインストール
まずWindowsアプリケーションのインストールメディア（CD-ROM）が、次のように設定されているとする。ここにインストーラであるsetup.exeが格納されているとしよう。
| Linuxのマウントポイント | ~/CD-drive/ |
| Wineでのマウントポイント | F:\ |
Windowsアプリケーション同様、そのインストーラもアプリケーションであり、Wineから起動することになる。
コマンド中でアプリケーションのパスを指定するに際し、wineprefix内のフォルダに格納されているならば、Windowsのパス、あるいはLinuxのパス、いずれを指定してもよい。
| Windowsのパスを指定する |
LANG=ja_JP.UTF-8 wine start 'F:\setup.exe' |
|---|---|
| Linuxのパスを指定する |
LANG=ja_JP.UTF-8 wine start /unix ~/CD-drive/setup.exe |
インストール先となるwineprefixも指定するならば、さらにコマンドの先頭へwineprefixのパスを追加する。次のような具合だ。
WINEPREFIX=~/.local/share/winegui/prefixes/Windows10-64
この投稿では、Microsoft/Shogakukan Bookshelf Basic Ver 2.0をインストールする。そのインストール・メディアは、まさに以上のような状態でマウントされている。つまり、上記コマンドのいずれかを実行すれば、そのインストールが始まるのだ。
インストール完了後、同様に、Bookshelfの実行ファイルを指定してコマンド実行すれば、Bookshelfが起動する。
WINEPREFIX=~/.local/share/winegui/prefixes/Windows10-64 LANG=ja_JP.UTF-8 wine start 'C:\Program Files (x86)\Microsoft Reference\Bookshelf Basic 2.0\bs98jl.exe'
 |
 |
 |
余談
デスクトップ・メニュー上のアイコン(アイテム)の編集
目的とするWindowsアプリケーションごとに、専用のWineprefixを用意するとしよう。それをコンテナ的に作っては消し、を繰り返していくとLinuxデスクトップ・メニューにアプリケーションのアイコンが多数、登録されていることに気づく。Wineprefixを削除しても、これらが削除されることはない。
これらを削除、あるいは編集するには、Linuxデスクトップの流儀に沿った対応が必要だ。日々、Linuxデスクトップを操作していながら、実際にはWindowsデスクトップほどの馴染みもない、と言うユーザーは、次の投稿を参照してほしい。
