WSLgアーキテクチャ

If you landed on this blog, you’ve probably seen our announcement for GUI applications support in the Windows Subsystem for Linux being available to Windows Insiders and looking for more details on how WSLg was built. If so, you’ve come to the right place!

情報源: WSLg Architecture | Windows Command Line

雑に翻訳。

このブログにたどり着いた方は、Windows Insidersに提供されるWindows Subsystem for LinuxのGUIアプリケーションのサポートについての発表をご覧になり、WSLgがどのように作られたかについての詳細をお探しだと思います。もしそうなら、あなたは正しい場所に来たのです。

理念と初期の目標

WSLでGUIアプリケーションのサポートを検討し始めたとき、すぐにX11とWaylandの両方のアプリケーションをサポートしたいと考えました。ユーザーがWSL内で実行したいと要望していたアプリケーションのほとんどはX11ベースのものでしたが、LinuxデスクトップコミュニティがWaylandに向かっていたので、それをサポートすることが重要だと考えました。Windows上のLinuxが過去に囚われ、X11アプリケーションに限定されたり、WSLgがWaylandへの移行の妨げになったりすることは避けたかったのです。

また、標準に忠実なLinuxアプリケーションのデスクトップ環境を構築することも重要でした。私たちは、アプリケーションが何の変更も必要とせず、そのままの状態で動作することを望んでいました。LinuxアプリケーションがWSLg内で動作するために、その動作を調整したり変更したりする必要はなく、WSLgがすべてのLinuxデスクトップ標準に徹底的に従うことで、物事がうまくいくようにしたかったのです。私たちはこれをオールラウンドなWin-Winだと考えました。フラグメンテーションを避け、アプリケーションの互換性を高め、ユーザーの満足度を高めることができます。もしそのような問題に遭遇したら、回避するのではなく、WSLgのGitHubプロジェクトに問題を提起して、私たちに知らせてください。

また、WSLgはオープンソースであり、WSL 2仮想マシンで実行されるLinuxとWindowsホスト間のすべての通信が、文書化された標準規格か、通信チャネルの両サイドで利用可能なオープンソースコードで定義されたものに従っていることを保証する必要がありました。シークレットソースは許されません。私たちは、コミュニティの開発者が望めばWSLgをいじれるようにしたかったのです。GitHubのWSLgプロジェクトには、アーキテクチャの概要と、WSLgのプライベートバージョンの構築と実行を開始する方法の詳細があります。

ユーザーエクスペリエンスの面では、統一された統合デスクトップを提供したいと考えました。LinuxとWindowsのアプリケーションが1つの統一されたデスクトップ上で隣り合って共存し、アプリケーションが予測可能な方法で動作するような体験です。世の中には、デスクトップ・オン・デスクトップのスタイルを提供するソリューションがたくさんあります。私たちは、WSLgがシームレスに感じられ、バックグラウンドに溶け込み、開発者が自分の仕事に集中して、LinuxやWindowsのアプリケーションを手間なく使用できるようにしたいと考えました。プレビュー版では、かなり良い体験を提供していますが、まだいくつかの気を散らす原因となる様々な制限があります。例えば、プレビュー版ではまだサーバーサイドでウィンドウの移動やサイズ変更を行っているため、ウィンドウの移動やサイズ変更の操作がネイティブのようにスムーズに行えません。また、Linuxのウィンドウをモニターの端にスナップさせたり、カスタムのスナップ領域にすることもできません。これらは私たちも困っています😊。私たちは、時間をかけてエクスペリエンスを向上させ、LinuxアプリケーションとWindowsアプリケーションの動作やパフォーマンスのギャップを減らしていきたいと考えています。一方で、これらのソリューションが私たちの基本原則に沿って設計されていることも確認しています。

ウェストンをベースに道を選ぶということ

私たちは、WaylandファーストのLinuxデスクトップとしてWSLgを構築し、xorgコミュニティが構築したXWaylandサーバーをホストすることで、X11アプリケーションをサポートすることにしました。

私たちにとっての大きな問題は、このWaylandコンポジターを作るために、どこから始めればいいのかということでした。新しいコンポジターを一から作るのか?Waylandプロトコルをホストにリモート接続して、Windows上で新しいコンポジターを実行するのか?それとも、既存のプロジェクトの上に構築して貢献するのか?

これは私たちにとって全く新しい分野であり、Linuxコミュニティの賢明な人々からの意見が必要だと考えました。私たちは、Windows上でLinuxのGUIアプリケーションを実現したいということを全世界に向けて発表する準備ができていなかったので、これまで一緒に仕事をしてきた信頼できる人たちに連絡を取りました。特に感謝したいのは、WSLのGitHubコミュニティで特に親切で活発なメンバーであるKenneth Clark氏です。Kennethは、//build2020で公開された、後にWSLgとなる最初の概念実証のためのプロトタイプの構築を手伝ってくれました。そして、Collabora社のDaniel Stone氏は、MesaプロジェクトのD3D12ガリウムドライバーで広範囲に協力してくれました。ダニエルの洞察力、視点、そしてWaylandとWestoneに関する豊富な知識は、私たちの選択を正しく理解し、WSLgがしっかりとした基盤の上でスタートするために不可欠なものでした。

では、なぜウェストンをベースにしようと思ったのか。

一言で言えば、コミュニティが既に構築したものの上に構築し、可能な限り準拠したコンポジターを確保することができる最良のアプローチだと考えました……公式のWaylandリファレンスコンポジターを実行する以外に、これを達成する方法はありません

WestonはWSLgの心臓部です。様々なWaylandプロトコルを定義・実装しているWestoneコンポジターのフロントエンドは、バグフィックスや、アプリケーションのリモーティングに関する新しいパラダイムに対応する以外は、事実上変更されていません。WSLgはWestoneから新しいまたはプライベートなWaylandプロトコルを追加することはなく、Waylandアプリケーション(X11アプリケーションの場合はXWayland)に関する限り、Westoneと相互作用しています。これを観察する1つの方法は、アプリの互換性です…我々は、drmバックエンドに対して実行されるネイティブのWestoneと、かなり同等に近い状態です。一般的に、アプリケーションがWestoneネイティブで正しく動作する場合、WSLgでも正しく動作しますし、その逆も同様です。

私たちは、それが素晴らしいポジションだと感じています。私たちがWSLgのアプリの互換性の問題を修正し、その修正をアップストリームすることで、Westone(とWayland)をより良くすることができます。コミュニティがWestoneに修正を加えると、私たちもその修正から直接利益を得ることができます。アプリケーションの互換性を高めるのは長い道のりになると思いますが、Waylandプロジェクトのリファレンスコンポジターの上に構築することで、Waylandコミュニティとの連携が取れていると感じています。

WestonにはすでにRDPバックエンドがあり、FreeRDPを使ってMicrosoft標準のリモート・デスクトップ・プロトコル(RDP)でホストと通信することができました。既存のWestoneのRDPバックエンドを拡張して、新しい技を教えることは、私たちにとって非常に興味深いことでした。Windows側では、RDPをリモートアプリケーションに活用した経験がたくさんあります。Windows Virtual Desktop(WVD)は、Azureで稼働する世界規模のサービスで、世界中のユーザーにWindowsアプリケーションをストリーミングしています。WVDはRDP RAIL(Remote Application Integrated Locally)技術を使用して、これらのリモートアプリケーションをユーザーのローカルデスクトップ体験に統合しています。また、Windowsクライアント技術としては、Edgeや今回のOffice向けのWindows Defender Application Guardなどがありますが、これらはRAIL(Virtualized Application Integrated Locally)と呼ばれるRDP技術の一種であり、ネットワーク上ではなくVM境界上での転送に最適化されています。

Westonを拡張してアプリケーションリモーティングを教え、RDPのバックエンドを拡張してRAILとVAILの両方を活用することで、ネットワークの透明性を念頭に置いて、業界ですでに広く使われていて大規模に運用されているプロトコルを使って、ゼロから構築された一般的なソリューションを手に入れることができ、これは非常に魅力的なことでした。

WSLgのアーキテクチャ

WSLgの心臓と魂はWestoneコンポジターです。これは、標準的なWestoneコンポジターに、大幅に拡張されたRDPバックエンド、新しいRAIL/VAILシェル、そしてあちこちでの様々なバグフィックスを加えたものです。現在、私たちはプロジェクトミラーからこれらのコンポーネントを構築していますが、その間、私たちの貢献をそれぞれのプロジェクトに戻すアップストリーム作業を行っています。最終的には、純粋にアップストリームのコンポーネントからWSLgを構築し、WaylandやWestoneをいじりたい人たちにとって、WSLgが素晴らしくてシンプルな生産環境になることを目標としています。

RDPのバックエンドを様々な方法で拡張しました。RAILおよびVAIL(別名:GrfxRedirection)プロトコルを使用したアプリケーションのリモーティングをサポートしました。RDPバックエンドでは、デスクトップ全体ではなく、個々のウィンドウをリモートすることが可能になりました。RAILとVAILの違いは、RAILはRDPトランスポート上にウィンドウのピクセルコンテンツをコピーし、ネットワーク上に接続されたRDPサーバー(WSLg)とRDPクライアント(ホスト上)に最適化されていることです。VAILはRAILと非常によく似ていますが、VM境界上のトランスポートに最適化されています。VAILはホストとゲストのVM間で共有メモリを使用し、RDPトランスポート上での高価なピクセルコピーを回避します。WSLgの構築の一環として、VAIL/GrfxRedirectionプロトコルを公開しています。

アプリケーションのリモーティングに加えて、RDPバックエンドが拡張され、モニターごとのDPIスケーリングのサポートを含むマルチモニター構成がサポートされるようになりました。DPIスケーリングでは、Waylandでネイティブにサポートされているスケールファクターに対してはWaylandのネイティブサポートを、サポートされていないスケールファクターに対してはRDPクライアントサイドスケーリングを組み合わせて使用しています。これにより、ユーザーがWindowsのUI設定で選択した環境設定に基づいて、Linuxアプリケーションが常に適切にスケーリングされるようになります。クリップボードのサポートが追加され、LinuxとWindowsアプリケーションの間でテキスト、HTML、ビットマップデータのカット&ペーストが可能になりました。ドラッグ&ドロップは現在サポートされていません。

オーディオの入力と出力の両方に対応しました。オーディオについては、PulseAudio サーバーを使用することにしました。PulseAudio と RDP バックエンドの間でオーディオデータをシャッフルし、RDP トランスポートを介してローカルまたはリモートの RDP クライアントにオーディオストリームを統合できるようにするための、Pulse 用の小さなシンクおよびソースプラグインを作成しました。

WSLGdは小さなデーモンのようなアプリケーションで、WSLg環境で最初に起動するプロセスであり、Westone、Pulseを起動し、ホストとのRDP接続を確立し、これらを監視し、クラッシュしたり動作が停止した場合は再起動します。

WindowsのスタートメニューにWSLgを統合するための小さなRDPプラグインを書きました。Westonの内部にあるプラグインの部分は、ユーザーのディストロにインストールされたアプリケーションを列挙し、デスクトップファイルを探します。Westonの内部にあるプラグインの部分は、ユーザーのディストロにインストールされているアプリケーションを列挙し、デスクトップファイルを探します。そのアプリケーションのリストを、起動するためのコマンドラインとそれを表すアイコンとともに、プラグインのホスト部分に送り、ユーザーのスタートメニューにこれらのアプリケーションを追加し、WindowsのスタートメニューからLinuxアプリケーションを直接起動できるようにします。いくつかの標準的なデスクトップファイルの場所が監視されます。ユーザーがLinuxディストロのアプリケーションをインストールしたりアンインストールしたりすると、その操作が数秒後にWindowsホストに反映されます。

最後に、FreeRDPを拡張して新しいプロトコルをサポートするとともに、mstscとの通信におけるいくつかの互換性の問題を修正しました。WestonはすでにRDPのサポートにFreeRDPを使用していましたが、別のソリューションに移行する必要はないと考え、代わりにFreeRDPにいくつかの機能強化を行うことにしました。

システムディストロ

上の写真で、システムディストロと呼ばれる新しいものに気づいたかもしれません。システムディストロは、コンテナ化されたLinux環境と考えることができ、その中でWestoneや友人たちを走らせ、様々なサーバーソケットをユーザーディストロに投影しています。ユーザーディストロはデフォルトで、X11、Wayland、オーディオのサポートのためにこれらのサーバーを参照するように設定されています。

WSLgをユーザー・ディストロから切り離すことができるため、WSLgにはこの方法を採用することにしました。WSLgはユーザー・ディストロとは独立してサービスを提供することができ、異なるLinuxディストリビューションでも一貫した体験を提供することができます。WSLgを導入するにあたり、新機能の追加、パフォーマンスの向上、操作性の改善、アプリケーションの互換性問題の修正を継続して行うため、今後数ヶ月の間に頻繁にアップデートを行う予定です。システム・ディストロに手を加えたいユーザーのために、プライベート・バージョンを実行するためのメカニズムを提供しています(WSLg contributeページを参照)。

システム・ディストロには、WSLgをホストするためにCBL-Marinerを使用することにしました。CBL-Marinerは、軽量でカスタマイズ可能なLinuxディストリビューションで、当社のLinuxシステムグループによって管理されています。これにより、マイクロソフトのさまざまな部分にまたがるLinux環境のメンテナンスを一元化し、セキュリティ脆弱性やその他の重要なパッチを確実に入手して最新の状態を保つことができます。これまでCBL-Marinerは、Azureやエッジ製品・サービスで動作するヘッドレス、コンテナ型のワークロードに焦点を当てていました。CBL-Marinerチームと協力して、WSLgを実現するための様々なUI関連パッケージをCBL-Marinerの公式RPMリポジトリに公開しました。

WSLg project on GitHub

WSLgのアーキテクチャについてさらに詳しく知りたい方、ソースコードを見て自分で作ってみたい方は、GitHubにあるWSLgプロジェクトの公式ページをご覧ください。

OpenGLのハードウェアアクセラレーション

以前、WSLにおける仮想GPUのサポートを発表しましたが、これにより、一般的な計算APIをネイティブに近いパフォーマンスでWSLで利用できるようになります。これは、マイクロソフトが独自に開発したTensorflow用のDirectMLバックエンドに加えて、幅広いハードウェアに対応したWSLでのAIトレーニングを可能にするものです。

vGPUに加えて、私たちはMesaコミュニティと協力してMesa用の新しいd3d12 galliumドライバーを開発してきましたが、先日、この作業がWindows上で可能になったことを発表しました。これにより、これまでサポートされていなかったARMベースのWindows PCでハードウェアアクセラレーションによるOpenGLおよびOpenCLのサポートが実現しました。

新しいd3d12 MesaドライバのLinuxサポートは、数週間前にMesaにアップストリームされ、公式Mesa 21.0リリースの一部となっています。これは長い道のりの集大成であり、WSLgでハードウェアアクセラレーションによるOpenGLアプリケーションを可能にします。

WSLgは、vGPUやアクセラレーションされたOpenGLの有無に依存していないことが重要です。WSLgは、OpenGLアクセラレーションがあってもなくても、単純な2Dアプリケーションには最適です。しかし、BlenderやGazeboなどのより複雑な3Dアプリケーションを実行しようとする場合、WSL vGPUサポートに標準装備されているWDDMv3.0をサポートするGPUを搭載したシステム上で実行した方が、はるかに優れた体験を得ることができ、Mesaを通じてこのOpenGLアクセラレーションを自動的に点灯させます。

下記のリンクを利用して、各パートナーのWDDMv3.0ドライバーのプレビューを見つけることができます。これらのドライバーは、Windowsの次のバージョンがリリースされたときに、Windows Updateや新しいシステムとともに出荷される予定です。

Mesaに関しては、現在ほとんどのディストリビューションが古い20.xバージョンのままです。私たちは、様々なWSL Linuxディストリビューションのパブリッシャーに連絡を取り、Mesa 21.xへのアップデートが予定されていること、そして新しいd3d12 galliumドライバをビルドして含めるようにMesaパッケージの定義を更新することを確認しました。

あなたがこの文章を読んだときには、古いバージョンのMesaを使っているかもしれないので、WSLgのアクセラレーションOpenGLがあなたのシステム上ですぐに点灯するかどうかはわかりません。もし、あなたのディストロがこれらの変更に対応するのを待ちたくなく、すぐにでもこの機能を試したいのであれば、Mesaの公式ホームにアクセスして、このサポートを備えたMesaのプライベートバージョンをビルドすることができます。あるいは、Canonical社が最近発表した「Ubuntu on Windows Community Preview for WSL 2」を試すこともできます。このUbuntuの新しいディストリビューションは、最先端のコンポーネントで構築されており、Mesa 21.0をサポートしているため、WSLgでシームレスなハードウェアアクセラレーションによるOpenGLがすぐに利用できます。このディストリビューションは、WSLの上級ユーザーが今後の機能のテストやデバッグを行うためのものであり、「毎日使う」ものではありませんが、これらの機能をいち早く体験するには最適なものです。

ネイティブ版とWSLg版のアプリケーションを比較したい方もいらっしゃると思いますので、パフォーマンスについてメモしておきます😊。WSLg v1では、Mesaはシステムメモリを介してWestoneと相互作用します。ディスクリートGPUの場合、レンダリングされたコンテンツは、コンポジターに表示される前にシステムメモリにコピーされ、Windows上で動作するRDPクライアントでGPUに戻される必要があります。このコストはフレームレートに比例して増加し、超高フレームレートで動作するアプリケーションは、より妥当なフレームレートで動作するアプリケーションよりも大きな影響を受けます。統合されたGPUの場合、データはシャッフルされるのでシステムメモリから離れる必要はありませんが、Mesaを介したプレゼントは現在のところ同期的で、つまりフレームごとに小さなバブルが発生し(レンダリングを待ち、レンダリングされたフレームをプッシュし、次のフレームを開始する)、パフォーマンスに影響を与えます。

ここでは、私の2台のPCから取った完全に非公式なパフォーマンスの断片を紹介します。1つ目は、非常に高いフレームレートを実行するディスクリートGPU(特に悪いケース)、2つ目は統合GPU(特に良いケース)です。これはGeeks3D GpuTestのピアノ版です。

Native Win32 (Mesa)WSLg (vGPU – Mesa)WSLg (Software – Mesa)
NVIDIA RTX 3090
(Yeah, super lucky to have friends in right places)
540fps350fps
4fps
Surface Book Gen3 (Intel – GPU)19fps18fps
1fps

システムメモリのインターロップを行う必要があるため、パフォーマンスの低下は避けられませんが、結果としてソフトウェアレンダリングよりもはるかに優れたパフォーマンスを実現しています。WSLgで動作するネイティブのWin32アプリケーションとLinuxアプリケーションのパフォーマンスの差を縮めることは、WSLg v2以降で改善していきたいと考えていますが、v1では、ネイティブでなくても良いパフォーマンスを提供しつつ、コアな体験にエネルギーを集中させたいと考えました。

フィードバック

私たちは、WSLgについて、うまくいった点、そうでない点などのご意見をお待ちしています。問題が発生した場合や提案をしたい場合は、WSLgの公式プロジェクトページで問題を提起してください。

Windows Subsystem for Linux(WSL)でのGUIサポートの初期プレビューリリース

A year ago at BUILD 2020 we introduced our goal to bring Linux GUI applications to the Windows Subsystem for Linux (WSL) to run Linux GUI applications. We are proud to announce the first preview of this highly anticipated and open source feature!

情報源: The Initial Preview of GUI app support is now available for the Windows Subsystem for Linux | Windows Command Line

雑に翻訳。

1年前のBUILD 2020では、LinuxのGUIアプリケーションをWindows Subsystem for Linux(WSL)で動作させるという目標を紹介しました。この待望のオープンソース機能の最初のプレビューを発表できることを誇りに思います。私たちはこの機能に「WSLg」というニックネームをつけました。この機能をどのように利用できるか、どのように動作するか、そしてどのようにインストールするかについては、以下のビデオをご覧いただくか、このままお読みください。

GUIアプリケーションのサポートはどのように利用できるのか?

WSLではLinux環境を構築することができますが、これまではコマンドラインツールのユーティリティーやアプリケーションを利用することが中心でした。今回のGUIアプリのサポートにより、お気に入りのLinux GUIアプリケーションも使用できるようになりました。WSLは様々なアプリケーション、ワークロード、ユースケースで使用されているため、GUIアプリケーションのサポートをどのように使用するかはお客様次第です。以下では、Linux環境でアプリケーションを実行することを好きになってもらうために、いくつかの重要なシナリオを紹介します。

お好みのIDEを使ってLinuxプロジェクトを開発

Visual Studio Codeは、VS Code Remoteを使用して、Windowsマシン上で本格的なLinux IDEを直接使用し、Windowsと異なるWSLディストロの両方で拡張機能や設定を維持する方法を作成して、素晴らしい経験をしています(VS Codeチュートリアルを始めるには、こちらをご覧ください。WSLgは、gedit、JetBrainsベースのエディタ、gvimなどの他のIDEを実行して、Linuxアプリケーションのテスト、ビルド、デバッグを効率的に行うことができます。

ここでは、geditとgvimを実行して、WSLでLinuxのファイルを直接編集する例を紹介します。

Linuxのみのアプリケーションや、テストなどのLinuxに特化したユースケースの実行

この機能を使えば、Linuxにしか存在しないようなGUIアプリケーションを実行したり、自分のアプリケーションやテストをLinux環境で実行したりすることができます。クロスプラットフォームのアプリケーションをテストしたい開発者にとっては、マシンを変更したり仮想マシンを管理したりすることなく、Windows 10上で直接アプリケーションを実行したり、Linuxの中で簡単に実行したりできるので、非常に便利です。

WSLでTestCafe Studioを実行して、Linuxで動作するMicrosoft EdgeブラウザからWebテストを行う例を見てみましょう。

オーディオまたはオーディオサポートが組み込まれたマイクを使用するLinuxアプリケーションの構築、テスト、使用

WSL上のLinux GUIアプリケーションは、オーディオとマイクをサポートしています。これにより、アプリケーションがオーディオキューを再生したり、マイクを利用したりすることが可能になり、ムービープレーヤーや通信アプリケーションなどの構築、テスト、使用に最適です。

ここでは、Linux上のAudacityを使って音声を録音し、再生する例を紹介します。

ボーナス:WSLのGPUアクセスを活用して、Linuxアプリケーションを3Dアクセラレーションで実行する

この機能の一部として、GPUで加速された3Dグラフィックスのサポートも可能になりました。Mesa 21.0で完了した作業により、複雑な3Dレンダリングを行うアプリケーションは、OpenGLを活用して、Windows 10マシンのGPUを使用してこれらを加速することができます。これにより、ロボットシミュレーションツール「Gazebo」のような複雑なアプリケーションもスムーズに動作するようになります。この機能は、近々、さまざまなWSLディストリビューションにデフォルトで搭載される予定ですが、このブログ記事の指示に従って、適切なグラフィックドライバを入手し、お使いのディストリビューションに互換性のあるMesaバージョンがあることを確認すれば、すぐに利用することができます。

下の写真は、仮想の洞窟を探索するロボットをシミュレートするGazeboアプリケーションと、ロボットのカメラフィードとレーザーフィールドセンサーの出力を視覚化するRvizアプリケーションです。GPUアクセラレーションによる3Dグラフィックスのおかげで、このデモを60FPSで実行することができました。

この機能の仕組みは?

上のデモでは、Xサーバーを手動で起動する必要がないことにお気づきでしょうか。この機能では、Wayland、Xサーバー、Pulseオーディオサーバーなど、LinuxのGUIアプリケーションがWindowsと通信するために必要なものがすべて含まれたコンパニオンシステムディストロが自動的に起動されるからです。GUIアプリケーションの使用が終わり、WSLの配布を終了すると、システムディストロも自動的にセッションを終了します。

WSL 配管の他の部分と同様に、私たちの意図は、このコンポーネントが完全に管理され、ユーザーにとってシームレスであることです。私たちの意図は、このシステム・ディストロがユーザーにできるだけ見えないようにすることであり、wsl -l -vを実行してもこのシステム・ディストロが見えないのはそのためです。最後に、今回のシステムディストロには、マイクロソフトのCBL-Marinerディストリビューションを使用していることを発表します。CBL-Marinerは、マイクロソフトのクラウドインフラやエッジ製品・サービスに伝統的に使用されてきた内部Linuxディストリビューションですが、今回、WSL内のGUIアプリをサポートするために使用を拡張しています。この機能のアーキテクチャの全体的な概要については、以下の図をご覧ください。

この機能を実現するために行ったことや技術的な詳細については、この機能を実現した開発者が書いたブログ記事をご覧ください。

この機能を使い始めるには

この機能をWSLエクスペリエンスに完全にロールアウトする前に、初期プレビューとしてロールアウトを開始しています。Linux GUIアプリのサポートを使い始めるには、Windows 10 Insidersのプレビュービルド21364以降を使用していることを確認する必要があります。すでにWSLがインストールされている場合は、wsl --updateを実行するだけで、GUIアプリの使用が可能になります。WSLが有効になっていない場合は、wsl --installを実行すると、WSLの初期設定の一部としてWSLgが自動的にインストールされます。

インストール手順の詳細は、GitHubリポジトリのREADME: https://github.com/microsoft/wslg に記載されています。また、最高のパフォーマンスを得るために、WSLのGPUコンピューティングサポートを有効にすることを強くお勧めします。この機能を有効にする方法については、インストール手順のこのセクションをご覧ください。

フィードバック

技術的な問題や、GUIアプリケーションサポートのための機能要求は、WSLgのGithubリポジトリに提出してください。WSLの一般的な問題については、WSLリポジトリに提出してください。また、私のツイッター@craigaloewenや、このリストを使ってツイッターをしているすべてのWSLチームのメンバーをフォローすることができます。今後もWSLのエキサイティングな発表をこのブログでお届けしますので、ご期待ください。

石坂追記 日本語まわりに関して

Windows Inside Previewをアップデートして試してみました。

Windowsアプリケーションとの日本語を含むテキストのコピー・アンド・ペーストについては、これは両方向で上手くいきません。基本的にWSLのLinux環境がUTF-8で、Windows環境がUTF-16/CP932であることがその理由です。このため、WindowsのシステムロケールをUTF-8にすればワンチャンあるかもです。(試してはいません。)

WSLg/WSL2の日本語表示、日本語入力環境ですが、以下のサイトの情報が参考になりました。また、WSLgでのlinux GUIアプリケーションに対しては、WindowsのIMEからは日本語入力出来ず、linux側でIMEのセットアップが必要です。この辺は改善してほしいなと。

WSL2でつくる快適なUbuntu環境Ⅱ – Tadashi Aikawa

Windows 10 Insider Preview Build 21364

Hello Windows Insiders, today we are releasing Windows 10 Insider Preview Build 21364 to Windows Insiders in the Dev Channel.What’s new in Build 21364Run Linux GUI applications directly on Wi

情報源: Announcing Windows 10 Insider Preview Build 21364 | Windows Insider Blog

Dev Channel向けリリース。

WSLでGUIアプリケーションがサポートされました。その他はタスクマネージャーの改善、日本語の50音順タッチキーボードの追加(ギガスクルール向けなんだろうか?)とバグ修正。