Wine、デスクトップ、標準規格の話題LinuxWorld Toronto(1/4 ページ)

LinuxWorld Conference & Expo Torontoの最終日では、Wineプロジェクトや、Linux Standard Base、Linuxデスクトップに関して見事な発表を目にすることができた。

» 2006年05月02日 08時00分 公開
[David-Graham,japan.linux.com]
SourceForge.JP Magazine

 トロント発――LinuxWorld Conference & Expo Torontoの最終日は忙しい1日になった。Novell CanadaのCTO、ロス・シュバリエ氏は、なぜ今年が――これまでの年とは違って――Linuxデスクトップ導入の年であるかについて基調講演を行った。また、Free Standards Groupの取締役ジム・ゼブリン氏はLinux Standard Baseの重要性を語り、開発者ウルリッチ・クゼカッラ氏はWineプロジェクトの現状について見事な発表を行った。

 クゼカッラ氏の発表は、Wineプロジェクト(Wineはエミュレータではない)によるLinux向けWin32API実装の状況を明らかにするもので、Wineの下で実行されたMicrosoft PowerPointを使って行われた。クゼカッラ氏がWineに取り組み始めたのは1999年。当時の勤め先CorelがWordPerfectとCorelDrawをLinuxでサポートするためにWineを必要としていたころだ。現在、クゼカッラ氏は、独立して仕事を請けているが、Wine関連ではCodeWeaversとの仕事に多くの時間をかけているという。

 クゼカッラ氏は、Wineプロジェクトの重要性を説き、Open Soruce Development Labs(OSDL)による調査結果を引用した。Linuxへの移行を考える企業の最大の懸念が、新しい環境でもアプリケーションがこれまでどおり実行できるかどうかという点にあることを示す結果だ。ここでのアプリケーションとは、Microsoft Officeをはじめ、オープンソースの代替ソフトウェアが存在するものではなく、Visual Basicのプログラムのように社内で開発されたものやニッチ市場向けのものなど、その企業にとって重大な役割を担うアプリケーションのことだ、と彼は説明する。

 もともとWineプロジェクトは、Linux環境でゲームを動かすために1993年に始まった。エミュレータではなく、フリーのWin32 API実装で、Windows実行ファイルをLinux環境で実行できるようにするものだ。Wineは、GNU Lesser General Public License(LGPL)の下でリリースされている。また、Wineの開発に携わる開発者は665人にのぼり、うち常時30〜40人が活動しているという。

 Linuxシステム上のどのレベルでWineが動作するかを示す図を使って、オペレーティングシステムと実行中のプログラムとの間にあるレイヤーがどのように構成されているかが説明された。Wineは、カーネル空間ではなくユーザー空間で実行される。そのため、Wineからハードウェアやドライバにアクセスすることはできない。Linuxマシンから見れば、Wineは単なるアプリケーションに過ぎない。Windows実行ファイルの読み込みに必要なライブラリとカーネルとの間でWineは動作し、そのおかげでWindowsプログラムは、必要なWindowsライブラリをLinuxシステム内から見つけ出すことができる。

質問を受けるクゼカッラ氏

 理論的には、Wineで実行されるアプリケーションはWindows環境と同じ速さで実行できるはずだ、とクゼカッラ氏は言う。エミュレーションが行われていなければ、動作を遅らせる要因はどこにもない。しかし、Wineは依然として安定版のリリースとはみなされておらず、最適化もまだ行われていない。その結果、パフォーマンスが低くなっているのだ。Wine開発者の取り組みは、当面、最適化ではなく動作させることに注力して行われる。高速化に取りかかるのはその後でなければならない、と彼は話している。

 Wineの開発が進むにつれ、多くの労力が、ある特定のアプリケーションを動作させることに集中して注がれるようになっている。クゼカッラ氏によると、あるアプリケーションで使えるようになった機能はほかのアプリケーションでも必要とされるため、対象アプリケーションの問題を修正すると、ほかの多くのアプリケーションもWineで動作するようになるそうだ。WineでMicrosoft Office 2003を動作させると、副作用によってほかのプログラムにまで「付帯的損害」が及ぶ、という例が紹介された。

 ほとんどのLinuxディストリビューションには、Wineが含まれている。しかし、さまざまなプログラムでWineを使うには手作業による調整がまだ必要になることが多く、開発着手から13年たった今でもバージョンは0.9だ、とクゼカッラ氏は語る。Wineのリリース版には常にバグが潜んでいるため、突然のクラッシュに備えておく必要がある、と彼は注意を促す。Wineのサポートには、WindowsとLinuxの両方に精通した人物が必要だという。

 Wineのデバッグを行うには、Wineが落ちた原因を突き止める過程で、ギガバイトほどの大きさになることもある巨大なリレーログを参照してWineの動作の進行によってアプリケーション内部で何が起こったかを確認する必要がある、と彼は話している。小さなバグの修正であれば1つにつき約1000ドル、もっと難しいバグの修正になると4000〜2万ドルものコストがかかるという。Wineの実装は素晴らしいものに見えるかもしれないが、数々の問題を内包しており、費用のかかるものになっている。

 Wineはどこへ向かっているのだろうか。クゼカッラ氏によると、厄介な問題が幾つか残っているらしい。その1つがComponent Object Model(COM)の実装だ。何年も取り組んでいるがまだ終わらず、Microsoft Exchange Serverと通信できるようになるには少なくともあと6カ月はかかるという。

 現在、約7割のプログラムがMicrosoft Installerライブラリ(msi.dll)のWine実装を使ってインストールできる状態にある。1年後にはその比率は約9割になるとクゼカッラ氏は見込んでいる。しかし、インストールできたプログラムの大部分はインストール後の動作も問題ないはずだが、その保証はない、とも彼は述べている。Wineについてまわる問題として、デバイス独立ビットマップ(DIB)エンジンに関連したものもある。今のところ、Wineは24bit color depthのグラフィックにしか対応していないが、まだ多くのWindowsプログラムは16ビットのものだけを使っている。これはX環境にかかわる問題だ、と彼は述べている。

 Wineは、ユーザー空間のプログラムであり、ハードウェアが見えないため、Wineの下で実行されるプログラムからはUSBデバイス(USBキーなど)が直接見えない。この影響として、Digital Rights Management(DRM)を必要とするプログラムはWineでは動作しないし、LinuxがDRMをネイティブサポートしない限りこの問題は解決されない、と彼は説明する。また、DRMを利用している企業は協力に前向きではないという。DRMを実装していてWineでは動作しないプログラムの例として、彼はPhotoshopの最新バージョンを挙げている。

       1|2|3|4 次のページへ

Copyright © 2010 OSDN Corporation, All Rights Reserved.

注目のテーマ