実践： Microsoft が Windows 10 上の Linux GUI アプリケーションの最初のパブリック プレビューをリリースしたので、私たちはすぐにそれを試してみることにしました。
Windows Subsystem for Linux 2 で GUI アプリケーションを実行できる機能は目新しいものではありません。熱心なユーザーは長年にわたり、別途インストールした X サーバーユーティリティを介して GUI アプリケーションを実行できてきました。しかし、公式サポートの登場は、依然としてゲームチェンジャーと言えるでしょう。公式サポートは、様々な非公式アプローチよりも野心的で、より統合性が高くなっています。
このプレビューはWindows Insider Programを通じて提供され、開発者や愛好家は今後のリリースをいち早く確認できます。ダウンロード可能な最新ビルドは21354ですが、WSLgをサポートするのはビルド21364です。そのため、私たちのケースでは、ISOイメージから21354をインストールし、Insiderとして登録したMicrosoftアカウントでログインし、Windows Updateから新しいビルドがダウンロードされるのを待つだけで済みました。また、Hyper-V VMで実行することも選択しました。WSLもHyper-Vを使用しているため、これを行うにはネストされた仮想化を有効にする必要があります。そのためには、ホストマシンからPowerShellコマンドを実行する必要があります。
ビルド21364が起動したら、あとはwsl --install管理者権限のコマンドプロンプトから実行するだけです。WSLgが自動的に組み込まれるため、以前よりも多くの作業が必要になります。作業内容はかなり複雑です。WSLgでは、1台ではなく2台のWSL2 VMをインストールしていました。1台はユーザーディストリビューションのUbuntu、もう1台はMicrosoft独自のCBL-Mariner Linuxを使用した隠しシステムディストリビューションです。このディストリビューションは「Microsoftのクラウドインフラストラクチャとエッジ製品向けの社内Linuxディストリビューション」と謳っているため、今後数百万台のWindows 10 PCに導入されることは、その役割の大幅な拡大を意味します。
このシステムディストリビューションは、Waylandコンポジターのリファレンス実装であるWestonを実行しています。「WestonはWSLgの心臓部です」と、Microsoftのパートナー開発リーダーであるスティーブ・プロノヴォスト氏は述べています。このディストリビューションは、ユーザーがWindowsリモートデスクトップクライアントを使用して接続できるようにするFreeRDPと呼ばれるリモートデスクトッププロトコルサーバーを実行しています。MicrosoftはFreeRDPを拡張し、デスクトップ全体ではなく個々のウィンドウをサポートできるようにしました。また、モニターごとのDPIスケーリングとクリップボードのサポートを追加し、WindowsアプリケーションとLinuxアプリケーション間でカットアンドペーストを可能にしました。
WSLg の図では、RDP の役割と、Microsoft 独自の Linux を実行する 2 番目の隠し Linux ディストリビューションの役割を示しています。
WSLgのWestonは、もう一つの小さいながらも重要な役割を果たします。RDPプラグインが含まれており、ユーザーのディストリビューションをスキャンしてデスクトップアプリケーションを検索し、起動用のコマンドラインを含めてWindowsのスタートメニューに追加します。実際には、Linux GUIアプリケーションがネイティブWindowsアプリケーションと同じように検出・起動されるため、ユーザーエクスペリエンスに大きな違いをもたらします。
WSLgをインストールした状態でUbuntuにログインし、パッケージを更新してから「」と入力しましたsudo apt install gedit。GeditはGNOME標準のテキストエディタです。WSLのUbuntuはデフォルトで非GUIなので、最初のGUIアプリケーションをインストールすると多くのものがダウンロードされますが、うまく動作し、Geditがスタートメニューに「テキストエディタ（Ubuntu）」として正常に表示されました。起動すると、タスクバーにペンギンのオーバーレイアイコンと（私たちの場合）見苦しい「[警告：コピーモード]」というプレフィックスが付きます。コピーモードとは何でしょうか？これは、VAIL（Virtualized Application Integrated Locally）ではなく、ここで説明するリモートアプリケーションを表示する手段であるRAIL（Remote Application Integrated Locally）を使用していることを示している可能性があります。RAILはRDP経由でピクセルをコピーしますが、VAILはホストPCとWSL2 VM間で共有されるメモリを使用します。WSLgはVAILを使用するように設計されていますが、状況によってはRAILにフォールバックする可能性があります。ドキュメントによると、RAIL と VAIL の両方が FreeRDP に実装されるようになりました。
Linux GUIアプリケーションはWindowsのスタートメニューに自動的に表示されます
警告にもかかわらず、Gedit は正常に動作し、メモ帳との間でコピー＆ペーストも問題なく動作しました。さらに意欲的に、 を試してみましたsudo apt install libreoffice。この大規模なアプリケーションは多くの依存関係を伴いましたが、動作は良好で、スタートメニューに 7 つの追加アプリケーションが表示されました。これらは LibreOffice スイートのコンポーネントです。LibreOffice Writer は Windows デスクトップで起動し、「コピーモード」の警告にもかかわらず、問題なく動作しました。クリップボードのサポートには若干の不具合がありました。ホスト PC（Windows 10 を実行している VM のホスト）上の Word からテキストをコピーしようとすると「サポートされていません」というエラーが発生しましたが、その後の試行では正常に動作しました。
WSLgの開発者ストーリーは特に重要です。WSLの初期の推進力の多くは、Windowsで作業しながらLinuxサーバー向けアプリケーションを開発する開発者をサポートする必要性から生まれたからです。Windows上で動作するVisual Studio CodeはWSLのリモートサポートが優れていますが、代わりにVS CodeのLinuxビルドを実行する場合はどうでしょうか？
ちょっとしたことsudo apt install codeでうまくいきました。ソースコードがWSL2ファイルシステム上にある場合、このようにVS Codeを使うと少し手間が省けます。ちなみに、Linux GUIアプリでドキュメントを保存すると期待通りに動作し、Linuxのフローティング保存ダイアログが表示されます。このダイアログはデフォルトでWSL2側のユーザーのホームディレクトリに保存されます。Windowsホストファイルシステムも、例えば/mnt/c/Users/tim/Documentsからアクセスできます。
Windows 上で動作する Linux アプリケーション: Firefox、LibreOffice、Gedit、VS Code
WSLg から最高のパフォーマンスを引き出すには、VM ではなくベアメタルで実行し、WSL 側にハードウェアアクセラレーションされた OpenGL をサポートする GPU ドライバーをインストールする必要があります。これらのドライバーは AMD、Intel、Nvidia からプレビュー版として提供されていますが、ホストマシン自体が VM の場合は役に立ちません。これは、グラフィカルアプリケーションがハードウェアアクセラレーションされたパフォーマンスで実行されることを意味するため、重要です。また、WSL2 で実行される Nvidia の CUDA 言語などの汎用 GPU 開発も可能になります。これは、Linux サーバーなどに展開される AI および ML アプリケーションの開発において重要です。
まだ初期段階ですが、Windows 開発者にとって朗報となるでしょう。この技術が Windows 10 の大半に導入されれば、一般ユーザーにとっても朗報となるかもしれません。また、Windows を使っていない Linux 愛好家にとっても朗報です。Linux アプリケーションの潜在的なユーザーベースが大幅に拡大するからです。®
