Loading article…
Wine [ a ]は、 Microsoft Windows用に開発されたアプリケーション ソフトウェアやコンピュータ ゲームをUnix 系オペレーティングシステム上で実行できるようにする互換性レイヤーです。Wine は無料のオープンソースソフトウェアであり、著作権の問題を回避するために、主にブラックボックス テストのリバース エンジニアリングを使用して作成されています。
Wineは主にLinux、macOS、FreeBSD向けに開発されています。[ 10 ]開発者はWineLibを使用してWindowsアプリケーションをコンパイルし、 Unix系システムへの移植に役立てることができます。Appleシリコン搭載のMacコンピュータを除き、コードのエミュレーションや仮想化は行われません。Appleシリコン搭載のMacコンピュータでは、Rosetta 2を使用してx86_64コードをARMコードに変換します。
2007年にdesktoplinux.comが38,500人のLinuxデスクトップユーザーを対象に行った調査では、回答者の31.5%がWindowsアプリケーションを実行するためにWineを使用していると回答した。[ 11 ]この割合は、すべてのx86仮想化プログラムを合わせたよりも高く、Windowsアプリケーションを実行していないと回答した27.9%よりも高かった。[ 12 ]
初代プロジェクトリーダーのボブ・アムスタットとエリック・ヤングデールは、 Linux上でWindowsアプリケーションを実行する方法として、1993年にWineプロジェクトを開始しました。これは、 Sun Microsystemsの2つの製品、Solarisオペレーティングシステム用のWabiとPublic Windows Interface [ 13 ]に触発されたものです。Public Windows Interfaceは、 Windows APIをISO標準としてパブリックドメインで完全に再実装しようとする試みでしたが、 1996年にマイクロソフトからの圧力により却下されました。[ 14 ] Wineは当初、 Windows 3.xの16ビットアプリケーションを対象としていましたが、2010年現在、このプロジェクトは、新しいオペレーティングシステムの標準となっている32 ビット版と64 ビット版に焦点を当てています。このプロジェクトは、1993 年 6 月にusenetの comp.os.linux での議論から始まりました。 [ 15 ] Alexandre Julliard は1994 年以来このプロジェクトを率いています。
このプロジェクトは、主にWindows API のドキュメントが不完全で不正確なため、開発者にとって時間のかかる困難なものとなっています。Microsoft はほとんどの Win32関数を詳細に文書化していますが、ファイル形式やプロトコルなどの一部の領域については、Microsoft から公開されている完全な仕様がありません。また、Windows には、ドキュメント化されていない低レベル関数、ドキュメント化されていない動作、不明瞭なバグが含まれており、一部のアプリケーションが正しく動作するようにするには、Wine が正確に再現する必要があります。[ 16 ]その結果、Wine チームは、サンクなどの領域で多くの関数呼び出しとファイル形式をリバースエンジニアリングしました。
Wineプロジェクトは当初、 X Window Systemと同じMITライセンスでWineをリリースしましたが、Wineの独自バージョンがコアプロジェクトに変更を還元しないことへの懸念から、[ 17 ] 2002年3月以降の作業ではライセンスにLGPLを使用しています。[ 18 ]
Wineは2005年10月25日にバージョン0.9で正式にベータ版となりました。[ 19 ] 15年間の開発を経て、2008年6月17日にバージョン1.0がリリースされました。 [ 20 ]バージョン1.2は2010年7月16日にリリースされ、 [ 21 ]バージョン1.4は2012年3月7日に、[ 22 ]バージョン1.6は2013年7月18日に、 [ 23 ]バージョン1.8は2015年12月19日に、 [ 24 ]バージョン9.0は2024年1月16日にリリースされました。 [ 25 ]開発版はほぼ2週間ごとにリリースされます。
Wine-stagingは、WineHQ開発者によってWineリポジトリへのマージ準備が整っていないと判断されたものの、wine-compholioフォークでは依然として有用とみなされている、独立して維持されている積極的なパッチのセットです。主に実験的な機能とバグ修正を対象としています。2017年1月以降、wine-compholioがWineHQの主要開発者であるAlistair Leslie-Hughesにプロジェクトを移管したことにより、wine-stagingのパッチはWineHQの上流に積極的にマージされ始めました。2019年現在WineHQは、ワインステージングの既製バージョンも提供しています。[ 26 ]
Wineの主な企業スポンサーはCodeWeaversで、同社はJulliardをはじめとする多くのWine開発者を雇用し、WineとCodeWeaversがサポートするWineのバージョンであるCrossOverの開発に取り組んでいます。CrossOverには、アップストリームバージョンには適さないと考えられるアプリケーション固有の調整や、いくつかの独自のコンポーネントが含まれています。[ 27 ]
カナダのソフトウェア開発会社Corelは、一時的にこのプロジェクトを支援し、主にJulliardらを雇用して作業にあたらせた。Corelは、自社のオフィススイートであるWordPerfect OfficeをLinux（特にCorel Linux）に移植することに関心を持っていた。その後、MicrosoftがCorelに多額の投資を行い、Wineの開発を中止したため、CorelはLinux関連のプロジェクトをすべて中止した。[ 28 ]
その他の企業スポンサーには、CodeWeavers を雇って Wine を修正し、Picasa がWindows と同じバイナリを使用して Linux に直接移植できるほど十分に動作するようにしたGoogleが含まれます。Google は後に、Wine のAdobe Photoshop CS2のサポートの改善に資金を提供しました。[ 29 ] Wine は、Google のSummer of Codeプログラムの定期的な受益者でもあります。[ 30 ]
ValveはCodeWeaversと協力して、 Microsoft WindowsゲームをLinuxベースのオペレーティングシステム上で動作させるためのWineベースの互換性レイヤーであるProtonを開発しました。Protonには、Win32関数のLinux固有の実装など、さまざまな理由でWineの上流では受け入れられないパッチがいくつか含まれています。
Wineの目的は、WineのユーザーがUnix系システム上で実行したいプログラムに必要なWindows APIを、完全に、または部分的に実装することです。
Microsoft Windows のプログラミング インターフェイスは、主にダイナミック リンク ライブラリ(DLL) で構成されています。これらには、カーネルのシステム コール、NTOS カーネル モード プログラム (ntoskrnl.exe) のラッパー サブルーチンが多数含まれています。一般的な Windows プログラムは、いくつかの Windows DLL を呼び出し、それがさらにユーザー モード gdi/user32 ライブラリを呼び出し、さらにシステム コールを介してカーネルを扱う役割を担う kernel32.dll (win32 サブシステム) を使用します。システム コール レイヤーは、ドキュメントが公開されていないため、Microsoft プログラマー専用のものと考えられており、公開されているインターフェイスはすべてカーネル上で動作するサブシステムに依存しています。これらに加えて、個別のプロセスとして実行されるサービスとして実装されたプログラミング インターフェイスが多数あります。アプリケーションは、RPC を介してユーザー モード サービスと通信します。[ 31 ]
Wine は、カーネル モジュールとしてではなく、完全にユーザー スペースでWindowsアプリケーション バイナリ インターフェイス(ABI)を実装します。Wine は、Windows のカーネル[ 32 ]で通常提供されるサービスを、代わりにwineserver と呼ばれるデーモンによって提供する階層構造をほぼそのまま反映しています。wineserver の役割は、基本的な Windows 機能の実装、X Window Systemとの統合、およびシグナルをネイティブの Windows 例外に変換することです。wineserver はWindows カーネルのいくつかの側面を実装していますが、Wine の基盤となるアーキテクチャのため、ネイティブの Windows ドライバを使用することはできません。[ 31 ]
Wine の設定は、主にcontrol (Wine のWindows コントロール パネルの実装)、regedit (Wine のWindows レジストリエディター ツール)、winecfg (GUI 設定ツール)、およびその他多数のプログラムによって管理されます。デフォルトでは、Wine は設定ファイルとインストールされた Windows アプリケーションを~/.wineに保存します (インストール時に別途指定しない限り)。このディレクトリの場所は、 Wineプレフィックスまたはボトルと呼ばれます。wineprefix環境変数を使用して別のプレフィックスを指定することができ、これを使用すると使用する設定が変わります。[ 33 ] [ 34 ]
Wine は、Windows プログラム用に Windows DLL と Unix共有オブジェクトの両方をロードできます。最も基本的なWindows DLL、つまりNTDLL、KERNEL32、GDI32、USER32の組み込み実装は、ホスト オペレーティング システムの関数も使用する必要があるため、共有オブジェクト方式を使用します。WineD3D などの高レベル ライブラリは、DLL 形式を自由に使用できます。多くの場合、ユーザーは Wine によって実装された DLL の代わりに Windows から DLL をロードすることを選択できます。そうすることで、Wine でまだ実装されていない機能を提供できますが、Wine に存在しないものに依存している場合は誤動作を引き起こす可能性もあります。[ 31 ]
ほとんどのオフィスソフトウェアは複雑なGPUアクセラレーションによるグラフィックスAPIを利用しませんが、コンピュータゲームは利用します。これらのゲームを適切に実行するには、Wineは描画命令をホストOSに転送し、ホストOSが理解できる形式に変換する必要があります。
DirectX は、レンダリング、オーディオ、入力のための Microsoft API のコレクションです。2019 年現在、Wine 4.0 にはVulkan API用の DirectX 12 実装と OpenGL 用の DirectX 11.2 が含まれています。[ 36 ] Direct2D のサポートは Direct2D 1.2 に更新されました。[ 36 ] Wine 4.0 では、描画コマンドをホスト OS に渡すか、macOS の場合はMoltenVKによってMetal APIに変換することで、Wine が Vulkan アプリケーションを実行できるようになります。[ 36 ]
Wine の DirectX 関連の取り組みの多くは、Direct3D およびDirectDraw API 呼び出しからOpenGLへの変換レイヤーである WineD3D の構築に費やされています。2019 年現在、このコンポーネントは DirectX 11 までサポートしています。[ 36 ] 2016 年 12 月 12 日現在、Wine はD3D11 を使用してOverwatch を実行できるほど十分な性能を備えています。[ 39 ] Wine で使用される以外にも、WineD3D DLL は Windows 自体でも使用されており、古い GPU で新しい DirectX バージョンを使用したゲームを実行したり、古い DDraw ベースのゲームを正しくレンダリングしたりすることができます。[ 40 ]
Direct3D バックエンドを Vulkan API に移行するための作業が進行中です。Direct3D 12 のサポートは 4.0 で「vkd3d」サブプロジェクトによって提供されており、[ 36 ] WineD3D は 2019 年に Vulkan API を使用するように実験的に移植されました。[ 41 ]別の実装であるDXVK は、Direct3D 8、9、10、および 11 の呼び出しも Vulkan を使用して変換しており、別のプロジェクトです。[ 42 ]
Wine は、パッチを適用すると、 OpenGL API 呼び出しに変換することなく、無料のオープンソースGallium3D State Tracker (別名 Gallium3D GPU ドライバー) を介して Direct3D 9 API コマンドを直接実行することもできます。この場合、Gallium3D レイヤーは DX9 描画コマンドを直接パススルーできるため、パフォーマンスが最大 2 倍向上します。[ 43 ] 2020 年現在、このプロジェクトは Gallium.Nine という名前です。現在は独立したパッケージとして利用可能で、パッチを適用した Wine バージョンは不要です。[ 44 ]
Wineは通常、コマンドラインインタープリタから起動されますwine program.exe。[ 45 ]
winecfg基本的なオプションを調整するためのコントロールを備えたグラフィカルユーザーインターフェイスを起動するユーティリティがあります。 [ 46 ]これは、Wine に付属する GUI 構成ユーティリティです。Winecfg を使用すると、レジストリを直接編集する必要がなくなるため、Wine の構成が簡単になりますが、必要に応じて、付属のレジストリエディタ (Windows のregeditに似ています) を使用してこれを行うことができます。
アプリケーションによっては、正しく動作させるために、単にアプリケーションをインストールするだけでは不十分で、Wine を特定のWindows DLL を使用するように手動で構成するなど、より多くの調整が必要になる場合があります。Wine プロジェクトは、このような回避策をWine コードベースに統合せず、代わりにWindows APIの Wine 実装の改善にのみ注力しています。このアプローチは、Wine の開発を長期的な互換性に集中させますが、回避策を必要とするアプリケーションをユーザーが実行することを困難にします。その結果、 Wine 自体でそのまま動作しないアプリケーションの使用を容易にするために、多くのサードパーティ アプリケーションが作成されました。Wine wiki には、現在および廃止されたサードパーティ アプリケーションのページがあります。[ 47 ]
WineのDirect3D部分の開発者は、ゲームのサポートを強化するためにピクセルシェーダーなどの新機能を実装し続けています。[ 59 ] WineはネイティブDLLを直接使用することもできるため、機能が向上しますが、DLLがアプリケーション自体と一緒に配布されていない限り、Windowsのライセンスが必要になります。
Wineには、メモ帳、ワードパッド、コントロールパネル、インターネットエクスプローラー、Windowsエクスプローラーなど、いくつかのWindowsプログラムの独自のオープンソース実装も含まれています。[ 60 ]
Wineアプリケーションデータベース（AppDB）は、どのWindowsプログラムがWineと連携できるか、またその連携性能について、コミュニティによって維持されているオンラインデータベースです。
Wine は、 Windows 3.1x用に書かれたものを含む、従来の Windows アプリケーションとの良好な下位互換性を保証します。[ 61 ] Wine は、一部のプログラムに必要なさまざまな Windows バージョンを模倣でき、Windows 2.0まで遡ることができます。[ 62 ]ただし、Windows 1.xおよび Windows 2.x のサポートは、Wine 開発バージョン 1.3.12 から削除されました。システムに DOSBox がインストールされている場合( MS-DOSについては後述)、Wine 開発バージョン 1.3.12 以降では、模倣する Windows バージョンの「Windows 2.0」オプションが表示されますが、MS-DOS と Windows の機能が現在統合されていないため、Wine はほとんどの Windows 2.0 プログラムを実行できません。
Wine の後方互換性は一般的に Windows よりも優れています。新しいバージョンの Windows では、古い Windows アプリケーションをアップグレードせざるを得なくなり、オペレーティングシステムの変更に合わせてプログラムを調整する人がいないため、サポートされていないソフトウェアが永久に動作しなくなる可能性があります。多くの場合、Wine は「互換モード」を使用して新しいバージョンの Windows よりも優れたレガシー サポートを提供できます。Wine は、 x86-64 (64 ビット) CPUを使用する 64 ビット オペレーティングシステム上で16 ビットWindows プログラム ( Win16 ) を実行できます。 [ 63 ]これは、64 ビットバージョンの Microsoft Windows にはない機能です。[ 64 ] [ 65 ] WineVDM を使用すると、16 ビット Windows アプリケーションを 64 ビットバージョンの Windows 上で実行できます。[ 66 ]
WineはWindowsコンソールアプリケーションを部分的にサポートしており、ユーザーはコンソールを管理するために使用するバックエンドを選択できます（選択肢には、raw streams、curses、user32などがあります）。[ 67 ] raw streamsまたはcursesバックエンドを使用する場合、WindowsアプリケーションはUnixターミナルで実行されます。
64ビットWindowsアプリケーションの暫定的なサポートは、2008年12月にWine 1.1.10に追加されました。[ 68 ] 2019年4月現在 2 つの Wine バージョンは別々にビルドされるため、wine64 をビルドすると、x86-64 アプリケーションのみを実行できる環境が生成されます。[ 69 ]
2019年4月現在 Wine は、 WoW64ビルドを安定してサポートしており、同じ Wine インスタンス内で 32 ビットと 64 ビットの両方の Windows アプリケーションを実行できます。このようなビルドを実行するには、まず 64 ビット バージョンをビルドし、次に 64 ビット バージョンを参照して 32 ビット バージョンをビルドする必要があります。Microsoft の WoW64 と同様に、32 ビット ビルド プロセスは、32 ビット プログラムを処理するために必要な部分を 64 ビット ビルドに追加します。[ 69 ]この機能は少なくとも 2010 年以降確認されています。[ 70 ]
Microsoft Windowsの初期バージョンはMS-DOS上で動作し、WindowsプログラムはMS-DOSプログラムに依存して動作する場合があります。WineはMS-DOSを十分にサポートしていませんが、開発バージョン1.3.12以降、システムにDOSBoxが利用可能な場合は、 WineはDOSBoxでMS-DOSプログラムを実行しようとします。 [ 71 ]バグのため、WineはWindows 1.xおよびWindows 2.xプログラムをMS-DOSプログラムとして誤って識別し、DOSBoxで実行しようとして失敗します。[ 72 ]
WineはWinelibを提供しており、これにより、Windows APIの共有オブジェクト実装をUnixプログラムの実際のライブラリとして使用できます。これにより、WindowsコードをネイティブUnix実行ファイルに組み込むことができます。2010年10月以降、WinelibはARMプラットフォームでも動作します。[ 73 ]
Solaris SPARCのサポートはバージョン1.5.26で終了しました。
WineはARM（およびARM64/AArch64）プロセッサと、その上で動作するWindowsの派生版を一部サポートしています。 2019年4月現在 Wine は、ロック解除されたWindows RTデバイス向けに設計された ARM/Win32 アプリケーションを実行できます(ただし、Windows RT プログラムではありません)。Windows CE (x86 または ARM) のサポートは欠けていますが、[ 74 ] 、WineCE と呼ばれる非公式のプレアルファ概念実証バージョンでは、一部のサポートが可能です。[ 75 ]
2013年2月3日、ブリュッセルで開催されたFOSDEMの講演で、アレクサンドル・ジュリアールはGoogleのAndroidオペレーティングシステム上で動作するWineの初期デモを披露した。[ 76 ]
Android (x86 および ARM) 用の WINE の実験的なビルドは 2017 年後半にリリースされました。それ以来、公式開発者によって定期的に更新されています。[ 5 ]デフォルトのビルドではQEMUを介したクロスアーキテクチャ エミュレーションは実装されていないため、ARM バージョンでは Win32 API を使用する ARM アプリケーションのみを実行できます。[ 77 ]
Wineは、デフォルトでは、 MicrosoftのInternet Explorerと.NET Frameworkの代わりに、 Windows専用のGeckoとMonoのビルドを使用します。WineにはJScriptとVBScriptの実装が組み込まれています。これらのプログラムのMicrosoftインストーラーは、winetricks経由でダウンロードするか、手動で実行することも可能です。
Wine は、ほとんどのバージョンの Internet Explorer (IE) を十分にサポートしていないことが知られています。比較的最近のバージョンの中で、Wine の AppDB でそのまま使用可能な評価を報告しているのは、Windows XP 用の Internet Explorer 8 だけです。[ 78 ]ただし、Google Chrome は(Wine 5.5-staging の時点で) ゴールド評価を受けており、[ 79 ] Microsoft の IE の後継 Web ブラウザである Edge は、そのブラウザをベースにしていることが知られています (Microsoft 独自のレンダリング エンジンから切り替えた後[ 80 ] )。Winetricks は Internet Explorer 6 から 8 の自動インストールを提供しているため、これらのバージョンは組み込みの回避策で正常に動作することが期待できます。
Internet Explorer を直接インストールする別の方法として、現在は開発が停止しているIEs4Linux を使用する方法があります。これは最新バージョンの Wine とは互換性がなく、[ 81 ] IEs4Linux の開発は停止しています。
Wine の中核開発は、Windows API 全体の正しい実装を目指しており、特定のアプリケーションとの互換性の面で遅れをとることがありました。たとえば、Direct3D は 1998 年まで未実装のままでしたが[ 82 ]、新しいリリースでは実装がますます完全になっています[ 83 ] 。
CodeWeaversは、 Microsoft Officeやその他主要なWindowsアプリケーション（一部のゲームを含む）を実行するためにCrossOverを販売しています。CodeWeaversはAlexandre Julliardを雇用してWineの開発に取り組んでおり、LGPLの下でWineプロジェクトにコードの大部分を提供しています。CodeWeaversはまた、2007年1月10日にIntelベースのApple Macintoshコンピュータ向けにCrossOver Macという新しいバージョンをリリースしました。 [ 84 ]上流のWineとは異なり、CrossOverは特にmacOSのx64専用バージョンでも動作することができ、「wine32on64」と呼ばれる技術を使用しています。[ 85 ] [ 86 ]
2012年現在、CrossOverにはCrossOver GamesとCrossOver Proの両方の機能が含まれているため、CrossOver GamesとCrossOver Proは単体製品としては入手できなくなりました。[ 87 ]
CrossOver GamesはWindowsのビデオゲームを実行するために最適化されました。CrossOverとは異なり、Wineの最も安定したバージョンを提供することに重点を置いていません。代わりに、新しいゲームをサポートするために実験的な機能が提供されています。[ 88 ]
2018 年 8 月 21 日、Valve は、同社のSteamソフトウェアの Linux 版 (Linux ベースのSteamOSオペレーティングシステムに組み込まれた Steam インストールやSteam Machineコンピュータを含む) と統合するように設計された、Proton という新しい Wine のバリエーションを発表しました。[ 89 ] Valve の Proton の目標は、Linux 上の Steam ユーザーがネイティブ Linux ポートがないゲーム (特に古いカタログのゲーム) をプレイできるようにすることです。最終的には、Steam との統合とメインラインの Wine に対するゲーム サポートの改善により、Linux 上でネイティブにゲームをプレイする場合と同じ「シンプルなプラグ アンド プレイ エクスペリエンス」をユーザーに提供することを目指しています。[ 89 ] Proton は発表後すぐにパブリック ベータ版になりました。[ 89 ]
Valve は 2016 年以来 CodeWeavers と協力して Wine のゲームパフォーマンスの改善に取り組んでおり、その一部はアップストリームの Wine プロジェクトに統合されています。[ 89 ] Proton に組み込まれた具体的な改善点には、vkd3dを介したVulkanベースの Direct3D 9、10、11、12 の実装、[ 90 ] DXVK、[ 42 ]およびD9VK [ 91 ]、esync を介したマルチスレッドのパフォーマンス改善、[ 92 ]フルスクリーン ゲームの処理の改善、およびより優れた自動ゲーム コントローラー ハードウェア サポートが含まれます。[ 89 ]
Protonは完全にオープンソースであり、GitHub経由で入手可能です。[ 93 ] 'GEproton'などのProtonのフォークも人気を集めています。 [ 94 ]
ロシアの企業Etersoftは、2006年からWineの独自バージョンを開発している。WINE@Etersoftは、人気のロシア製アプリケーション（例えば、1C Companyの1C:Enterprise）をサポートしている。[ 95 ]
Wineのソースコードを使用しているその他のプロジェクトには、以下のようなものがあります。
ワインプロジェクトは、長年にわたり、技術面および理念面に関する数多くの苦情や懸念を受けてきた。
Wine は Windows バイナリ コードを実行できるため、ネイティブの Windows ウイルスやマルウェアが Unix ライクなオペレーティングシステムに影響を与えるという懸念が提起されています[ 114 ]。これは、Wine が Windows 用に作成された限定的なマルウェアを実行できるためです。2018 年のセキュリティ分析では、30 個のマルウェア サンプルのうち 5 個が Wine を介して正常に実行できたことが判明しました。これは比較的低い割合ですが、それでもセキュリティ リスクをもたらしました。[ 115 ]このため、Wine の開発者は、スーパー ユーザーとして実行しないことを推奨しています。[ 116 ] ZeroWine [ 117 ]などのマルウェア研究ソフトウェアは、仮想マシン内の Linux 上で Wine を実行し、マルウェアをホスト システムから完全に隔離します。仮想マシンを使用するパフォーマンス コストをかけずにセキュリティを向上させる代替手段として、AnboxソフトウェアがAndroidでデフォルトで行っているように、 LXCコンテナで Wine を実行する方法があります。
もう一つのセキュリティ上の懸念は、実装された仕様が不適切に設計されていて、セキュリティ侵害を許容する場合です。Wine はこれらの仕様を実装するため、それらに含まれるセキュリティ脆弱性も実装してしまう可能性があります。この問題の一例として、2006 年のWindows メタファイルの脆弱性があり、Wine が脆弱な SETABORTPROC エスケープを実装していました。[ 118 ] [ 119 ]
Wineに関する一般的な懸念は、Wineの存在によってベンダーがネイティブのLinux、macOS、BSDアプリケーションを開発する可能性が低くなるという点です。その一例として、IBMの1994年のオペレーティングシステムであるOS/2 Warpを考えてみる価値があります。ある記事では、OS/2を衰退させた弱点について述べており、その最初の弱点は次のとおりです。
OS/2 は DOS および Windows 3.1 アプリケーションとの優れた互換性を提供しました。いいえ、これは間違いではありません。多くのアプリケーションベンダーは、DOS または Windows アプリケーションを開発することで、DOS/Windows 市場に加えて OS/2 市場にも到達できると主張し、ネイティブの OS/2 アプリケーションを開発しませんでした。[ 120 ]
しかし、OS/2はエンドユーザーの受け入れにおいて多くの問題を抱えていた。おそらく最も深刻な問題は、販売されているコンピュータのほとんどに既にDOSとWindowsが搭載されており、多くの人が既にオペレーティングシステムを持っているため、OS/2のメリットを評価することさえしなかったことだろう。DOSとWindowsの「バンドル販売」と、それがオペレーティングシステム市場に及ぼした冷え込み効果は、米国対マイクロソフト社訴訟で頻繁に取り上げられた。
Wineプロジェクト自体は、そのWikiページの一つで、Windows APIの継続的な開発を「奨励」しているという具体的な苦情に対して次のように回答している。
ほとんどの人にとって、Windows に縛り付けるプログラムはいくつか残っています。Microsoft Office が Linux に移植されることは決してないのは明らかですが、TurboTax のような古いバージョンのプログラムも移植されません。同様に、移植されることのないゲームや社内アプリケーションが何万とあります。Linux を使用し、レガシー Windows アプリケーションに依存したい場合は、Wine のようなものが不可欠です... Wine は Linux をより便利にし、そうでなければ移行できなかった何百万人ものユーザーが移行できるようにします。これにより、Linux の市場シェアが大幅に上昇し、より多くの商用およびコミュニティ開発者が Linux に引き付けられます。[ 121 ]
また、Wine Wiki のページでは、Wine はデスクトップ上の Linuxの鶏と卵の問題を解決するのに役立つと主張しています。[ 122 ]
ここで、デスクトップにおけるLinuxの「鶏と卵」問題にたどり着きます。Linuxが上記のアプリケーションと同等の機能を提供できるようになるまでは、デスクトップ市場におけるLinuxのシェアは停滞するでしょう。しかし、デスクトップにおけるLinuxのシェアが上昇しない限り、どのベンダーもLinux向けアプリケーションを開発しようとはしないでしょう。この悪循環をどう断ち切れば良いのでしょうか？
ここでも、Wineが解決策を提供します。Wineは、ユーザーが時間とお金を費やしてきたWindowsアプリケーションを再利用できるようにすることで、Linuxへの移行を阻む障壁を劇的に下げます。これにより、Linuxはデスクトップ市場で急速に普及し、その分野での市場シェアを拡大することが可能になります。ひいては、企業が自社アプリケーションのLinux版を開発したり、Linux市場専用の新製品を開発したりすることが現実的になります。
Wineがソリティアしか実行できないのであれば、この論理は簡単に否定されるだろう。しかし、現在ではMicrosoft Office、QuickTimeやWindows Media Playerといったマルチメディアアプリケーション、さらにはMax PayneやUnreal Tournament 3といったゲームも実行できる。少し時間をかければ、他のほとんどすべての複雑なアプリケーションも快適に動作させることができる。そして、このリストにアプリケーションを一つ追加するたびに、他の多くのアプリケーションもその恩恵を受け、使えるようになるのだ。
Wine上でどのようなアプリケーションが実行できるかを知りたい場合は、弊社のアプリケーションデータベースをご覧ください。
ゲームに Wine を使用することは、Linux コミュニティでは特に物議を醸しており、一部の人々は、それがプラットフォーム上でのネイティブLinux ゲームのさらなる成長を妨げている、あるいは少なくとも阻害していると考えています。 [ 123 ] [ 124 ] [ 125 ]ただし、Wine は、現在の64 ビットWindows バージョンでは起動しない16 ビットおよび特定の32 ビットのアプリケーションやゲームを実行できるという特徴があります。[ 126 ]この使用例により、Windows Subsystem for Linuxまたはサードパーティの仮想マシンを介して Windows 自体で Wine を実行すること、また BoxedWine [ 127 ]や otvdm [ 128 ]などの手段でカプセル化することにつながっています。
2020年まで、マイクロソフトはWineについて公式な声明を発表していませんでした。しかし、Windows Updateオンラインサービスは、Wineで実行されているマイクロソフトアプリケーションのアップデートをブロックします。2005年2月16日、イヴァン・レオ・プオティは、マイクロソフトがWindowsレジストリでWine構成キーのチェックを開始し、コンポーネントのWindows Updateをブロックするようになったことを発見しました。[ 129 ]プオティが指摘したように、「マイクロソフトがWineの存在を認めたのはこれが初めてです」。
2020年1月、マイクロソフトはGoogle LLC対Oracle America, Inc.の訴訟におけるアミカス・キュリエ・ブリーフの中で、APIを再実装できることの肯定的な結果としてWineを挙げた[ 130 ] 。
2024年8月、マイクロソフトは.NET Frameworkの再実装であるMonoプロジェクトをWineの開発者に寄贈した。[ 131 ]
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク){{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)通常、利用可能なドキュメントから始め、関数の最初のバージョンを実装し、この関数を呼び出すアプリケーションで問題が見つかったら、アプリケーションが期待する動作になるまで動作を修正します。これは通常、ドキュメントに記載されている内容とはかなりかけ離れています。
との違いはいくつかあります。
[...]
C++ ではなく C で書かれており、恐ろしい多重継承に依存していません。
[...]
これまでのところ、nvc0 および r600g ドライバーで Skyrim、Civilization 5、Anno 1404、および StarCraft 2 を試しましたが、wined3d で得られる fps の最大 x2 でかなりうまく動作します (注: 徹底的なベンチマークはまだ行われていません)。
