シーズンは日本時間では木曜日23時30分に切り替わります。秋から冬になりました。
正確には4/22 23:30～4/29 23:30まで。
ほぼ2020-08-14からの再チャレンジ。
任意のOffroadマシンのフォトを撮る。
Razer Core X Chroma 外付けGPU(eGPU)BOX ThunderBolt 3 700W Windows Mac 両対応【日本正規代理店保証品】 RC21-01430100-R3J1
価格: 50,379円 
Razer(レイザー)のストア出版社 XXXX
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の心臓と魂は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のアーキテクチャについてさらに詳しく知りたい方、ソースコードを見て自分で作ってみたい方は、GitHubにあるWSLgプロジェクトの公式ページをご覧ください。
以前、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) | 540fps | 350fps | 4fps |
| Surface Book Gen3 (Intel – GPU) | 19fps | 18fps | 1fps |
システムメモリのインターロップを行う必要があるため、パフォーマンスの低下は避けられませんが、結果としてソフトウェアレンダリングよりもはるかに優れたパフォーマンスを実現しています。WSLgで動作するネイティブのWin32アプリケーションとLinuxアプリケーションのパフォーマンスの差を縮めることは、WSLg v2以降で改善していきたいと考えていますが、v1では、ネイティブでなくても良いパフォーマンスを提供しつつ、コアな体験にエネルギーを集中させたいと考えました。
私たちは、WSLgについて、うまくいった点、そうでない点などのご意見をお待ちしています。問題が発生した場合や提案をしたい場合は、WSLgの公式プロジェクトページで問題を提起してください。
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!
雑に翻訳。
1年前のBUILD 2020では、LinuxのGUIアプリケーションをWindows Subsystem for Linux（WSL）で動作させるという目標を紹介しました。この待望のオープンソース機能の最初のプレビューを発表できることを誇りに思います。私たちはこの機能に「WSLg」というニックネームをつけました。この機能をどのように利用できるか、どのように動作するか、そしてどのようにインストールするかについては、以下のビデオをご覧いただくか、このままお読みください。
WSLではLinux環境を構築することができますが、これまではコマンドラインツールのユーティリティーやアプリケーションを利用することが中心でした。今回のGUIアプリのサポートにより、お気に入りのLinux GUIアプリケーションも使用できるようになりました。WSLは様々なアプリケーション、ワークロード、ユースケースで使用されているため、GUIアプリケーションのサポートをどのように使用するかはお客様次第です。以下では、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にしか存在しないようなGUIアプリケーションを実行したり、自分のアプリケーションやテストをLinux環境で実行したりすることができます。クロスプラットフォームのアプリケーションをテストしたい開発者にとっては、マシンを変更したり仮想マシンを管理したりすることなく、Windows 10上で直接アプリケーションを実行したり、Linuxの中で簡単に実行したりできるので、非常に便利です。
WSLでTestCafe Studioを実行して、Linuxで動作するMicrosoft EdgeブラウザからWebテストを行う例を見てみましょう。
WSL上のLinux GUIアプリケーションは、オーディオとマイクをサポートしています。これにより、アプリケーションがオーディオキューを再生したり、マイクを利用したりすることが可能になり、ムービープレーヤーや通信アプリケーションなどの構築、テスト、使用に最適です。
ここでは、Linux上のAudacityを使って音声を録音し、再生する例を紹介します。
この機能の一部として、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のセットアップが必要です。この辺は改善してほしいなと。
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音順タッチキーボードの追加（ギガスクルール向けなんだろうか？）とバグ修正。
オブジェクト指向は最近もなんか議論になっているけど、とりあえず読むと良いかなーと言う本をまとめておきます。
オブジェクト指向、特にオブジェクト指向プログラミングに関しては本当に”Don’t think, feel.”なんで、書いているうちに体で気づくしかないものではあるのだけど、まぁそれもあんまりなので、読んどいた良い本はあります。古い本もあります。
最近10年ぶりに第3版が出ました。とりあえず何か一冊読むのであればこれです。オブジェクト指向プログラミング以外のオブジェクト指向分析・設計まで少し踏み込んでいるので、オブジェクト指向の擁護になれるためにも良いでしょう。
第一特集のオブジェクト指向プログラミングの記事が秀逸でした。おじさん達も頭の中をアップデートしておくために読んでおいた方が良いです。
いざ、オブジェクト指向を始めるのは良いのですが、身近に良いメンターがいないと必ず間違えます。その良いメンターの代わりのするのがこの本です。古い本で、中古しかないようですが、周りに良いメンターがいないばあいや、独学で学習を進めている方は入手して見てはいかがでしょうか。
UML モデリングのエッセンス 第3版 (Object Oriented SELECTION)
マーチン・ファウラー (著), 羽生田 栄一 (翻訳)
価格: 2,640円
翔泳社; 第3版 (2005/6/16)
今あまりUMLは重要視されていませんが、じゃコードで直接説明できない場合に、クラス（オブジェクト）とその関係をどの様に説明するかと言ったときには、UMLは今でも唯一の選択肢です。この本はUMLだけではなく、オブジェクト指向でのモデリングについても学習できるので、読むと良いでしょう。これも今となっては大分古くなったので、説明されているUMLのバージョンも古いものになっていますが、基本的に今でも問題ありません。
リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice)
Dustin Boswell (著), Trevor Foucher (著), 須藤 功平 (解説), 角 征典 (翻訳)
価格: 2,640円
オライリージャパン; 初版八刷 (2012/6/23)
内容はオブジェクト指向に限りませんが、これはぜひ読んでおきましょう。
All of our product development begins and ends with you—whether you posted on Developer Community, filled out a survey, sent us feedback, or took part in a customer study, thank you for helping to continue to steer the product roadmap for Visual Studio.
情報源: Visual Studio 2022 | Visual Studio Blog
64bit化とともに刷新されるVisual Studioにわくわくしますね！
以下雑に訳しました。
Developer Communityに投稿していただいた方、アンケートにご協力いただいた方、フィードバックを送っていただいた方、カスタマー・スタディに参加していただいた方など、Visual Studioの製品ロードマップの策定にご協力いただき、ありがとうございました。この夏、Visual Studio 2022の最初のパブリック・プレビューがリリースされます。
Visual Studioの次のメジャー・リリースでは、より速く、より親しみやすく、より軽量になり、学習者と産業規模のソリューションを構築する人の両方に向けて設計されています。また、Visual Studioは史上初めて64ビット化されます。ユーザー・エクスペリエンスは、よりクリーンでインテリジェント、そしてアクション指向になります。
開発チームはこれまで以上に地理的に分散しています。昨年来、企業は開発チームが安全にコラボレーションし、より迅速にソリューションを提供し、エンドユーザーの満足度と価値を継続的に向上させることを必要としていることが明らかになりました。私たちは、GitHubとの連携を強化することで、アイデアからコード、そしてクラウドへの移行をシームレスにし、コラボレーションを容易にします。
Visual Studio 2022は、64ビットアプリケーションとなり、メインのdevenv.exeプロセスのメモリが～4gbに制限されることはなくなります。Windows上で64ビットのVisual Studioを使用すれば、最大かつ最も複雑なソリューションであっても、メモリ不足になることなく、開き、編集し、実行し、デバッグすることができます。
Visual Studioは64ビットになりますが、Visual Studioで構築するアプリケーションの種類やビット数は変わりません。Visual Studioは、今後も32ビットアプリケーションを構築するための優れたツールであり続けます。
1,600のプロジェクトと約30万のファイルを含むソリューションを開く際に、64ビットプロセスで利用可能な追加メモリを使用するためにVisual Studioがスケールアップしているこのビデオを見て、私は本当に満足しています。もうメモリ不足の例外は起きません。🎉
また、ソリューションの読み込みからF5のデバッグまで、お客様のワークフローのあらゆる部分をより速く、より効率的にするために取り組んでいます。
お客様がより快適にご利用いただけるよう、ユーザーインターフェースを一新しました。変更点の中には、UIを現代的にしたり、複雑性を緩和するための微妙な化粧直しもあります。全体的には、複雑さを減らし、認知的な負荷を軽減することで、集中して作業を進められるようにすることを目指しています。また、Visual Studioをよりアクセシブルにすることで、誰もがより良い操作性を得られるようにしています。Visual Studioの次期バージョンには、以下の機能が含まれます。
開発者同士であれば、IDEをカスタマイズすることは、机の椅子を選ぶのと同じくらい重要なことだと理解しています。最も生産性を高めるためには、「ちょうどいい」状態にしなければなりません。これまで以上に、Visual Studio 2022を自分に合ったものにすることが容易になります。IDEのカスタマイズ機能から、複数の開発環境を所有している場合のデバイス間での設定の同期まで、様々な機能が提供されます。
Visual Studio 2022では、Azureを使ったモダンなクラウドベースのアプリケーションを素早く簡単に構築することができます。今日のアプリケーションで使用されている一般的なパターンを記述したリポジトリが充実しているので、安心して始められます。これらのリポジトリは、これらのパターンが実際に使用されていることを示す意見付きのコード、AzureリソースをプロビジョニングするためのInfrastructure-as-Codeアセット、プロジェクトを最初に作成する際に完全なCI/CDソリューションを設定する事前に構築されたGitHubワークフローとアクションで構成されています。さらに、必要な開発環境もリポジトリに定義されているので、すぐにコーディングやデバッグを始めることができます。
Visual Studio 2022では、WindowsとMacの両方の開発者を対象に、.NET 6とそのWeb、クライアント、モバイルアプリ用の統合フレームワークを完全にサポートします。これには、Windows、Android、macOS、およびiOS上のクロスプラットフォームのクライアントアプリ用の.NET Multi-platform App UI（.NET MAUI）が含まれます。また、ASP.NET Blazorウェブ技術を使用して、.NET MAUIを介してデスクトップアプリを書くこともできます。
また、Web、デスクトップ、モバイルなどのほとんどのアプリタイプでは、.NET Hot Reloadを使用して、再起動やアプリの状態を失うことなくコードの変更を適用することができます。
Visual Studio 2022 には、新しい生産性機能、C++20 ツール、インテリセンスを備えた C++ ワークロードの強力なサポートが含まれます。C++20 の新しい言語機能により、大規模なコードベースの管理が簡素化され、診断機能の向上により、テンプレートやコンセプトを使用して困難な問題のデバッグが容易になります。
また、CMake、Linux、WSLのサポートも統合され、クロスプラットフォームのアプリケーションの作成、編集、ビルド、デバッグが容易になりました。また、Visual Studio 2022にアップグレードしたいが、互換性が心配という方も、C++ランタイムとのバイナリ互換性があるので安心です。
アプリケーションを自信を持ってデバッグする能力は、日々のワークフローの中心にあります。Visual Studio 2022では、コア・デバッガーのパフォーマンスが向上しているほか、ホット・パスをより正確に検出するためのプロファイラーのフレーム・チャート、より正確なデバッグのためのディペンデント・ブレイクポイント、ローカルにないコードをステップ・スルーできる統合デコンパイル・エクスペリエンスなどの追加機能が搭載されています。
Live Shareは、他の人との共同作業、アイデアの交換、ペアプログラミング、コードのレビューなどの新しい機会を提供します。Visual Studio 2022では、Live Shareに統合されたテキスト・チャットが導入され、コンテキストを切り替えることなくコードに関する素早い会話ができるようになります。また、同じリンクを再利用する定期的なセッションをスケジュールするオプションも用意されており、頻繁に連絡を取り合う相手とのコラボレーションが容易になります。また、組織内でのLive Shareのサポートを強化するために、セッションポリシーが導入されます。これは、コラボレーションに必要なコンプライアンス要件を定義するものです（例：読み書き可能な端末は共有可能であるべきか）。
Visual StudioのAI IntelliCodeエンジンは、あなたの次の行動をシームレスに予測する能力を高め続けています。Visual Studio 2022では、日々のワークフローへの統合がますます深化し、適切な場所で適切なタイミングで適切な行動を取ることができるようになります。
Visual Studio 2022には、GitとGitHubの強力なサポートが新たに追加されます。コードのコミット、プルリクエストの送信、ブランチのマージは、”私のコードが私たちのコードになる “ときです。マージとレビューのプロセスを効率的に進めるために、多くの組み込みロジックとチェックポイントが用意されており、作業を遅らせる可能性のある同僚からのフィードバックも想定されています。ここでの私たちの指針は、あなたが提供するコードに対してより高い信頼性を持てるようにすることでした。
コード検索は、ソフトウェア開発のライフサイクルにおいて重要な役割を担っています。他者からの学習、コードの共有、リファクタリング中の変更の影響の評価、問題の調査、変更のレビューなど、開発者はさまざまな理由でコード検索を使用します。Visual Studio 2022では、これらの重要な作業のパフォーマンスを向上させ、開発者の生産性をさらに高めることを目指しています。また、読み込んだ範囲外でも検索できるようになり、どのコードベースやレポにあっても探しているものを見つけることができるようになります。
Visual Studio 2022 for Macの目標は、Mac用にカスタマイズされた最新の.NET IDEを作成し、これまでのVisual Studioで培った生産性を提供することです。現在、Visual Studio for MacをmacOSのネイティブUIに移行する作業を進めており、これによりパフォーマンスと信頼性が向上します。また、Visual Studio for Macに組み込まれているmacOSのアクセシビリティ機能をすべて活用できるようになります。また、MacとWindowsの間でVisual Studioをより一貫したものにするため、IDE全体のメニューと用語を更新しています。また、Visual Studioの新しいGitエクスペリエンスは、Git Changesツール・ウィンドウの導入を皮切りに、Visual Studio for Macにも導入される予定です。
ここでは、現在進行中の作業の一部をご紹介しましたが、Visual Studio 2022の方向性について、皆様からのご意見をお待ちしております。新設されたDeveloper Communityでは、既存の機能要求を閲覧してアップベートやコメントをしたり、独自の機能要求を作成したりすることができますので、ぜひご利用ください。
64ビット版Visual Studio 2022 Preview 1の発表をお楽しみに！UIの改良やアクセシビリティの向上が含まれています。(そして覚えておいてください! 他の進行中の作業と同様に、これらの機能はまだ開発中であるため、一部の機能は最初のパブリック・リリース後にVisual Studio 2022に搭載される予定です)。
ありがとう！
シーズンは日本時間では木曜日23時30分に切り替わります。夏から秋になりました。
正確には4/15 23:30～4/22 23:30まで。
ほぼ、2020/8/7からの再チャレンジ。
ブロードウェイの風車であなたの車の写真を撮ります。
Continue reading オータム #Forzathon 4/16～4/23 #ForzaHorizon4
本日アップデートがありました。500MB弱の容量なので、小規模な変更だと思われます。リリースノートはまだ公開されていません。
We’ve continued to enhance the Git tooling in Visual Studio and are excited to announce some long-awaited updates. We’ve built functionality that addresses gaps around discoverability, switching repositories, navigation, and more!
情報源: Enhanced Productivity with Git in Visual Studio | Visual Studio Blog
最初の変更点は、ステータスバーです。IDEウィンドウの右下にあるステータスバーのセクションには、すぐにアクセスできるGitコマンドのトレイが常駐しています。そして私たちは、その機能を拡張し始めました。
よく知られているブランチピッカーは、右端のボタンから始まり、Git Changes ウィンドウのブランチドロップダウンと同様の外観になりました。今回の刷新により、ブランチの検索や、リポジトリのローカルブランチとリモートブランチの切り替えができるようになりました。コンテキストメニューを使えば、どのツールウィンドウが表示されているかにかかわらず、ブランチに対して素早くアクションを実行できます。
ステータスバーのリポジトリボタンを選択すると、リポジトリピッカーの最初の繰り返しが表示されるようになりました。今のところ、ローカルリポジトリはすべてアルファベット順に表示され、リストをフィルタリングする機能もあります。近いうちに、このリストからアイテムを削除できるようになります。
バージョン管理されているフォルダーやソリューションを Visual Studio で初めて開くと、ローカルリポジトリのリストに Git リポジトリが表示され、ネストしたサブリポジトリも表示されます。リポジトリのリモートがAzure DevOpsでホストされている場合は、Git ChangesにAzure DevOpsプロジェクトへの接続を求めるプロンプトが表示されます。そうすると、そのプロジェクトのワークアイテムやビルドにアクセスできるようになります。また、最初の接続が確立されると、Visual Studioはその接続を記憶し、次にリポジトリを開いたときに自動接続されるようになります。
デフォルトでは、リポジトリを開くと、Visual Studio は関連するソリューション/フォルダーをソリューションエクスプローラーに読み込みます。リポジトリに複数のソリューションがある場合は、ソリューションエクスプローラーにソリューションのリストが表示されます。
ここにはいくつかのニュアンスがあります。あなたのソリューションがGitリポジトリの外にある場合があります。そのため、リポジトリを開くときには、たとえそれが別のフォルダにあったとしてもソリューションを開いておく必要があります。Git > 設定」で新しい環境設定を切り替えることで、この動作を有効にできるようになりました。それ以外のケースでは、Visual Studio は開いているリポジトリと開いているソリューションの間で一貫性を維持し、両者が同期しないことはありません。
ステータスバーの次のボタンは、まだコミットされていない変更されたファイルの数を表示します。このボタンは、「Git Changes」ウィンドウを開くためのショートカットになっています。
そして、ステータスバーの最後のボタンは「unpushed commits」ボタンです。このボタンは、まだリモートにプッシュされていないコミットの数を表示します。近いうちに、プッシュされていないコミットの数も表示されるようになるでしょう。このボタンをクリックすると、Fetch、Pull、Push、Sync（要望が多かったので復活しました）のクイックアクションを備えた新しいフライアウトが表示されます。
SyncはSynchronizeの略で、PullとPushを組み合わせたものです。Syncコマンドの利点は、ワンクリックでローカルブランチとリモートブランチを同期させることができることです。このコマンドは、トップレベルのGitメニューでも利用できます。これにより、Sync には独自のキーボードショートカット (Alt+G+S) が用意され、素早くアクセスできるようになります。また、どこにあるか忘れてしまった場合には、Ctrl+Qの検索ボックスで検索できるようにもなります。
Git リポジトリのウィンドウで最初に目につくのは、受信コミットと送信コミットのリストの常設場所です。これらのセクションには、ステータスバーやキーボードショートカット Ctrl+0+Y からアクセスできるようになりました。これらのセクションでは、まだプッシュやプルが行われていないすべてのコミットの概要を確認できます。「Fetch」を選択すると、「Incoming」セクションが表示されます。ローカルコミットを行うと、「Outgoing」セクションが表示されます。
発信されたコミットを見た後、次にしたいことは、そのコミットにどのような変更があったかを確認することです。これまでは、コミットを選択すると新しいツールウィンドウが開き、変更点を確認するために特定のファイルを選択するとさらに別のウィンドウが開きました。これではウィンドウが多すぎます。そこで、すべての機能をひとつのウィンドウに組み込みました。最初のファイルには、コミットの詳細と変更点のビジュアルが表示されています。また、ファイルのリストを下っていき、各ファイルの変更点をその場で確認することもできます。2つのコミットを比較するときも、ウィンドウは同じように動作します。
また、コミットの詳細を全画面で表示したい場合や、いくつかのコミットを別の画面に表示して変更点を深く掘り下げたい場合も、そのようにすることができます。ウィンドウのレイアウトは自由に変更できます。
ファイル比較の上部にあるツールバーでは、便利な情報を得ることができます。左側の表記は、そのコミットのファイルの削除数と挿入数を教えてくれます。右側のアクションを使って、サイドバイサイド表示からインライン表示などにレイアウトを変更することができます。
Git Changes ウインドウのステータス・セクションにあったボタンを、右上のオーバーフロー・メニューに統合しました。ここでは、複数のリモートを管理したり、それらに対してアクションを実行したりすることができます。このメニューからは、ナビゲーションのためのクイックアクションや、「設定」「ブランチ履歴」「ファイルエクスプローラー」「コマンドプロンプト」など、リポジトリに関連する他のウィンドウを開くこともできます。
新しい経験をするたびに、筋肉の記憶が変化していきます。そのため、新しいツールの使い方について、最新のガイダンスを提供することが重要だと考えています。そのために、Visual StudioでGitを学ぶための無料オンライン・コースを、ステップ・バイ・ステップの練習問題とともに用意しました。また、ドキュメントも更新され、バージョン・コントロールに関する記事が追加されています。
私たちの旅を最初から見守ってくださっている方も、今から参加される方も、まだまだこれからだということを知っておいてください。私たちは、Visual Studio で Git リポジトリを使用する際に役立つ多くの機能を構築する予定です。優先順位を決めるためにも、機能リクエストへの投票を続けていただき、私たちの活動状況をお知らせください。
We are excited to announce the release of Visual Studio v16.10 preview 2. This release continues a theme of developer productivity and convenience. We’ve added C++20 ranges, IntelliSense completions, and new features for testing, Docker tooling enhancements, and Git integration! Download the latest Visual Studio preview release to try the new features in 16.10.
情報源: Visual Studio 2019 v16.10 Preview 2 Releases Today | Visual Studio Blog
C++での機能向上、.NET(C#)での機能向上、Dockerコンテナ向けの機能向上、Git機能向上。
