Wine DoorsはWineToolsと同様のサポートツールで、Windows用疑似ドライブの設定やWindowsアプリケーションの追加など、Wineのインストール作業をユーザフレンドリ化してくれる。その最終的な目標はと言うと、Google Earthなどのフリーアプリケーションを始め、PhotoshopやInternet Explorerなどの商用ソフトウェアやMicrosoftから提供されているフォントパックなどのサポートパッケージを含めたWineベースアプリケーションの管理を、ユーザによるポイントアンドクリック操作で行えるようにすることだとされている。
WineToolsに付随するトラブル
そもそも開発者のKarl Lattimer氏がWine Doorsに手を染めた最初の動機はInternet Explorerに関連する問題だったとのことだ。WineToolsを用いたIEのインストールで繰り返しトラブルに見舞われた同氏は、自力で対策を図るべくWineToolsのコードを覗き見たのだが、そこでの発見は同氏の眉をひそめさせるのに充分なものであった。例えば、サポート対象のアプリケーションはツール中にコード化されているため、このシステムは柔軟性に欠けた構造となっており、リスト上で未サポートのアプリケーションを追加したければ、WineToolsの新規バージョンが登場するのを待つしかなく、エンドユーザにとっては大きなボトルネックとなっていた。
またWineの開発者コミュニティ側からもWineToolsについては、他のライブラリやアプリケーション群との協調性が欠如している点について不満の声が挙げられていた。本質的な問題はレジストリ設定が変更されることで、他のプログラムが想定しているデフォルト値が上書きされたことの帰結が、重大なバグレポートとしてWineの開発チームに報告されてきたものの、この問題を引き起こしていたのはWineToolsであってWine側ではなかったのである。より重要な問題は、多くの開発者がWineToolsの設計思想はWineプロジェクトの目標と相反していると感じていたことであり、それもそのはずで、WineToolsでダウンロードとインストールを行う正規のWindows用DLL群とは、Wineチームが依存性を無くそうと奮闘していたライブラリ群そのものなのであったからだ。
その他の問題は、WineToolsがシェルスクリプトで記述されている点で、既に廃止が確定的で定期アップグレードの行われなくなった旧式のGTK+1やXdialogでコーディングされていたことである。そしてこのコードベースは、オリジナルの開発者たちが放棄した後、現状維持のまま複数の開発チームに引き継がれてきたという経緯を有している。また、技術面および設計思想面に対して寄せられている批判意見を、現行のメンテナ陣も認めてはいるのだが、新規プロジェクトとして立ち上げ直すだけの時間もリソースもないため、遺憾ながらそうした問題について対処できることはほとんどないとのことだ。
とは言うものの、WineToolsのようなアプリケーションが必要とされているのも事実である。一説によると、最も多用されているWine用アドオンがこの種のソフトということだが、それを裏付けする理由としては、かなりの数のWineユーザはWindowsからの移行組であり、購入済みのWindows用アプリケーションを新たなオペレーティングシステムで動かす環境を構築する必要に迫られていることが挙げられている。またTransgamingなどWineの商用販売を手がけているところは、ポイントアンドクリック方式インストーラのマーケット開発を狙っており、既にCedegaゲームシステム用のインストーラの提供が開始されている。
新たな設計での再出発
舞台設定は既に整っていた、とでも言えばいいのであろうか。Lattimer氏が決意したのは、PyGTKを用いてより近代的なWineToolsの代替ツールをゼロから作り直すことで、その際にはコードのサイズと複雑さを大幅に削減できるGlade for the GUIを採用することであった。そして重要なのは、Wine開発陣との様々なオプションを検討した結果として、Wine Doorsではデザイン段階において、プログラムの本体とインストールおよび管理対象のWine用アプリケーションとをより明確に分離させるようにしたことである。この結果Wine Doorsは、リモートでの設定対応式アプリケーションリポジトリが利用可能となり、個々のパッケージ管理をコミュニティに任せる形でより柔軟な運用ができるようになっている。
Wine Doorsのインストーラモジュールで採用されているXMLベースの“アプリケーションパック”は、設定オプション、必要条件、ファイルパーミッション、その他のメタデータを指定するためのもので、Linuxのネイティブ.rpmおよび.debパッケージフォーマットと同様な扱いが行える。またWine Doorsアプリケーション本体は、アプリケーションパックおよびパックリストをリモートリポジトリから取得するが、ローカルキャッシュを保持することで高速な処理を可能としている。
このようにWine DoorsはWineプロジェクトで従来から用いられているAppDBとの統合が図られているが、これはDebianベースのLinuxディストリビューションがAPTを介してリモートリポジトリとリンクしているのと同様の関係になると見ていいだろう。だが話はそれだけでは終わらない。Lattimer氏が強調するのは、サードパーティ系の独立ソフトウェアベンダが独自のアプリケーションリポジトリを構築して運用することも可能だという点だ。プライベートなリポジトリの構築は、企業環境で活動するシステム管理者にとって有用な機能であり、実際Wineを用いてデスクトップ環境をLinuxに移行することへの期待は、ホームユーザよりも企業ユーザの方が大きいであろうと、同氏は語っている。
Lattimer氏の長期的な構想では、CedegaやCrossOver Officeを始め、その他の“特殊”なWineアドオンをアプリケーションに統合することを考えているという。もっとも現状の最優先事項は、コアとなる機能群を健全な状態に構築することである。Lattimer氏が現在共同で作業している開発者はThomas Dybdahl Ahle氏ただ一人であるが、ハードウェア抽象レイヤを改修してWine Doorsの認識するCDドライブ位置を変更可能にするなど、Wine Doorsに関する各種の機能向上においては同氏が多大な貢献をしてくれたとのことだ。
既に基本的なパックリストは準備されており、サブバージョンをチェックアウトして試用することができる。開発チームの希望するところでは、来月中に.rpmパッケージフォーマットでのリリース（必要なスキルを持った協力者が見つかれば.debも）を考えているのだが、その前に最初のエンドユーザリリースに向けてアプリケーションリポジトリのサポートを強化するためのテスタを募集しているところだとのことだ。
NewsForge.com 原文