このページの本文へ

前へ 1 2 次へ

Windows Info 第259回

WSL2ではRDPでLinux GUIアプリのウィンドウを表示する

2021年01月24日 10時00分更新

文● 塩田紳二 編集● ASCII

  • この記事をはてなブックマークに追加
  • 本文印刷

RDPで仮想マシンからのウィンドウ表示を高速化する

 RDPは通信を介して、表示を別のマシンにする仕組みだ。当初は、シンクライアントなどの非力なマシンを想定していたため、クライアント側の負荷や通信量が少なくなるように考えられていた。しかし、ネットワークは高速化し、同じ物理マシン上で実行される仮想マシンの表示をするとなると、考え方は大きく変わってくる。

 まず、仮想マシンとホストOS間では、ハイパーバイザーの機能を使って、コミュニケーションが可能だ。また、相手がホストWindowsだとすれば、VMとホスト間でのメモリ共有も難しくない。仮想マシンが専有しているメモリは、VMMEMという仮想的なプロセスが専有しているメモリとしてWindows側からは見えるようになっている。このため、ハイパーバイザー経由の通信で制御すれば、問題を起こさないように共有メモリを実現でき、グラフィックス描画のような比較的大きなデータでもやりとりが可能だ。

 RDPには、すでにこうした仕組みが装備されていると考えられる。これをMicrosoftは、VAIL(Virtual Application Integreated Locally)と呼ぶ。この名称は、前述のRAILと対になることを想定してのものだ。VAILでは、仮想マシン内で行われたGUIアプリケーションのウィンドウ描画は、共有メモリを介して、ホスト側に渡す。通信を前提としないため、VAILを使えば、WSL2側(ゲストOS側)からのウィンドウ描画を高速にホスト側のデスクトップに表示できる。

 さらに、WSL2側で仮想GPU(仮想GPUユーザーモードドライバー)が動作できるなら、共有メモリの描画イメージをCPUで扱うことなく、直接GPUがデスクトップに合成できるようになる(そもそもDWMではGPUを使ってウィンドウからデスクトップを合成している)。

 しかし、仮想GPUをWSL2側で動かすには、いろいろと準備が必要となる。そこで、共有メモリをソフトウェアでレンダリングすることも可能なようだ。ただし、Win32側がDirectX 11で動作している場合、DWMに引き渡す前に一回コピー動作が入り、表示速度が落ちることが考えられる。Windows 10では、Windows 7からのアップデートを許しているため、ハードウェア的には、DirectX 11の環境が残っている可能性もありえる。

 LinuxのGUIアプリケーションが動作するようになると、ユーザーの「Linux」への見方が大きく変わるような気がする。WSLが導入されてから、筆者のコマンドライン利用は大きく変わった。たとえば、原稿ファイルの文字数や行数を調べたいときにはWSL側のwc(Word Countプログラム)を使う、用語の置換などをawk(テキスト処理が可能な言語)で処理する、などだ。一時Unixで仕事していたこともあり、Unix/Linuxのコマンドラインには慣れていて、WindowsのcmdやPowerShellにちょっとした不満もあった。気軽にbashが使えるという環境は、LinuxとWindowsの両方を使うことができるユーザーには魅力があるように感じる。

 Linuxを中心に利用するユーザー、開発者なども、組織外とのやりとりでWordを使う必要があったり、あるいは、ExcelのVBAでデータを処理するといったときに、2つの環境を行き来するという不便があった。

 以前紹介したように、WSL2内でもNested VMで仮想環境が利用可能になり、さらにWSLGが導入されると、WSL2は“ほとんどLinux”と言っていいレベルになる。Linuxユーザーに対しては、WSLを使うという選択肢が提供され、Windowsユーザーには、Linuxがすぐに使えるというメリットが生まれる。そのときユーザーは、どういう動きになるのかに興味がある。

前へ 1 2 次へ

カテゴリートップへ

この連載の記事

注目ニュース

ASCII倶楽部

プレミアムPC試用レポート

ピックアップ

ASCII.jp RSS2.0 配信中

ASCII.jpメール デジタルMac/iPodマガジン