Windows11でディスプレイの解像度が「デスクトップ モード」と「アクティブなシグナル モード」で異なる場合の対処方法

Windows11でディスプレイを接続したとき、ディスプレイの解像度が正しく認識されないことがあった。具体的には、解像度が1280 x 1024という正方形に近い形のディスプレイを接続したとき、なぜか横幅を無理矢理縮めたような表示になった。

ディスプレイの詳細設定を確認すると、なぜかディスプレイの解像度が1920 x 1080と選択されており、「デスクトップ モード」と「アクティブなシグナル モード」で異なる解像度が表示されていた。

先ほどのおかしな表示は、おそらく1280 x 1024の解像度のディスプレイに無理矢理1920 x 1080の解像度を表示しようとした結果だと思われる。

一見すると、ディスプレイの解像度を変更することで正しく表示されるようになると思われる。

しかし、実際にはディスプレイの解像度を1280 x 1024に変更しても先ほどの横幅をさらに縮めたような表示になり、ますますおかしくなってしまった。

この症状は、「デスクトップ モード」と「アクティブなシグナル モード」で解像度が一致していないため発生していると思われる。なので、対処方法を簡単に書く。

対処方法

ディスプレイアダプターの設定画面から、適切な解像度のモードを選択する。なお、以下の手順では「アクティブなシグナル モード」の解像度を変更している。

1.設定アプリ→「システム」→「ディスプレイ」で表示がおかしくなっているディスプレイを選択し、「ディスプレイの詳細設定」を開く。

2.「ディスプレイ 2 のアダプターのプロパティを表示します」を押す。

3.「モードの一覧」を押す。

4.適切な解像度のモードを選択し、OKを押す。

私の場合は、「1920 x 1080,True Color (32ビット),60 ヘルツ」が選択されていたので「1280 x 1024,True Color (32ビット),60 ヘルツ」に変更した。

おわりに

ディスプレイの解像度とは別に、解像度に関する設定があることは知らなかった。結局のところ、なぜディスプレイの解像度と異なるモードが選択されていたのかは分からない。グラフィックスドライバとの相性の問題だろうか？

PowerShellのRemove-Itemでパスの長さ制限を回避してファイルを削除する方法

Windowsには、パス*1の長さが最大260文字までという制限がある。この制限については、以下の公式ページで詳しく解説されている。

learn.microsoft.com

以下、リンク先本文より引用。

Windows API では (次の段落で説明するいくつかの例外を除いて)、パスの最大長は MAX_PATH です。この値は 260 文字と定義されています。

確かにWindowsには上記の制限があるが、例えば外付けドライブで上記の上限を超えたファイルがあった場合、エクスプローラーからファイルを削除することができる。しかし、Remove-Itemではファイルを削除できずエラーになる。

レジストリを修正して最大値を変更する方法もあるが、この記事ではレジストリを修正せずにRemove-Itemでファイルを削除する方法を簡単に書く。なお、この記事ではWindows PowerShell 5.1を使用している。

方法

以下のように、削除するファイルの絶対パスの先頭に\\?\をつける。

$filepath = "（削除するファイルの絶対パス）"
$filepath = "\\?\" + $filepath
Remove-Item $filepath -Recurse -Force

解説

Windowsで使用されているパスの形式

Windowsには複数のパス形式があり、以下の公式ページで詳しく解説されている。

learn.microsoft.com

上記のページから、それぞれのパス形式について簡単にまとめる。

• 従来のDOSパス
  • Windowsでよく見かけるパスの形式。
  • 例：C:\test\123.txt、..\test\123.txt など
• UNC パス
  • ネットワーク上のリソースにアクセスするときによく使用されているパスの形式。
  • 例：\\192.168.1.1\test\123.txt、\\server01\test\123.txt など
• DOSデバイスパス*2
  • Windowsの内部で使用されているパスの形式。従来のDOSパスやUNCパスの先頭に\\?\もしくは\\.\をつける。この記事では、このパス形式を使用した。
  • 例：\\?\C:\test\123.txt など

なお、相対パスはデバイスパスには使用できない。それについては、先ほどの公式ページでも以下の通り記載されている。

DOS デバイス パスは定義によって完全修飾されており、相対ディレクトリ セグメント (. または ..) で始めることはできません。 現在のディレクトリが使用されることはありません。

なぜパスの長さ制限を回避できるのか

これについては、以下の公式ページで記載されている。

learn.microsoft.com

以下、リンク先本文より引用。

Windows API の多くの関数には、拡張パスに対応する Unicode バージョンもあり、その場合は最大合計パス長として 32,767 文字が許容されます。 この種類のパスは円記号で区切られたコンポーネントで構成されます。各コンポーネントの最大長は、GetVolumeInformation 関数の lpMaximumComponentLength パラメーターで返される値 (通常は 255 文字) です。 拡張パスを指定するには、"\\?\" プレフィックスを使用します。 たとえば、"\\?\D:\very long path" などです。

パスの先頭に\\?\を付けると、拡張パスとして260文字を超える文字列を認識できるようになるとのこと。

また、別の公式ページにも記載がある。

learn.microsoft.com

以下、リンク先本文より引用。

ファイル I/O でパス文字列に "\\?\" というプレフィックスを付けると、文字列の解析を無効にし、それに続く文字列をそのままファイル システムに送信するように Windows API に指示できます。 たとえば、ファイル システムが長いパスとファイル名をサポートする場合、Windows API によって適用される MAX_PATH 制限を超える可能性があります。

これらの情報から、パスの先頭に\\?\を付けると文字列のチェックを行わないため、結果として260文字を超えるパスを認識できるようになることが読み取れる。

おわりに

パスの長さ制限に引っかかることはめったにないが、まれに階層が深すぎるファイルや名前が長すぎるファイルに遭遇することがある。レジストリを修正するのも一つの手だが、私はファイルを削除するだけであればそこまでする必要はないと思う。

なお、Windowsのパスの書き方については以下のページが詳しい。

gigazine.net

正直、Microsoftの公式ページは開発者向けに書かれているためか内容がやや難しい。上記のページではパスの書き方が具体的に書かれているので、参考にどうぞ。

*1:コンピュータ上でファイルやフォルダの場所を示す文字列のこと。

*2:NTパスや拡張パスと呼ばれることもある。

RufusでUbuntuのLiveUSBメモリを作ってみた

私は「LinuxをLive起動*1させるならDVDが必要」と思い込んでいたが、最近のパソコンは大体USBメモリからのOS起動に対応している。いろいろ調べてみるとRufusというソフトを使ってUbuntuのLiveUSBメモリを作れることが分かったので、試しに作ってみた。

以下のサイトからRufusをダウンロードできる。

rufus.ie

利用頻度は低いので、私はポータブル版のRufusをダウンロードした。起動直後の画面はこんな感じ。

一見すると複雑そうだが、操作はとても簡単。「選択」を押してUbuntuのISOファイルを選択すると、以下のような画面になる。

「スタート」を押すと、LiveUSBメモリを作成できる。基本的には既定値のままで問題ない。私の場合は、5分程度で作成が完了した。

オプションで注意が必要なのは「パーティション構成」で、既定ではMBRが選択されている。MBR（マスターブートレコード）はWindows7ぐらいまでのやや古いパソコンで使われていたパーティション構成で、古めのパソコンで使うのであればMBRのままが無難。

作成したLiveUSBメモリを使ってみたところ、DVD起動よりも圧倒的に動作が速く快適だった。正直こうしたツールは謎のエラーを吐いたり作ってからも起動しなかったりとトラブルが起きやすいイメージがあったが、実際にはエラーもなく簡単に作成できた。いろんな方が、RufusでLiveUSBメモリを作る理由がなんとなく分かった気がした。

私はこれまで、UbuntuをLive起動させるときはDVDを使っていた。ただ、DVDからのLive起動は動作が遅いこと、LiveDVDの作成にやや時間がかかること、そして最近のUbuntuはISOファイルのサイズが6GBを超えており、DVD-Rでは容量オーバーになるため2層のDVD-R（DVD-R DL）が必要になることが不満点だった。

ネットでLinuxのLive起動について調べてみたが、今はUSBメモリを使ってLive起動することが主流なようで、CDやDVDを使っている記事はかなり少ない。私は新しいUbuntuのLTS版が出るたびLiveDVDを作ってきたが、LiveUSBメモリが快適だったので今後はUSBメモリに一本化するかもしれない。

*1:パソコン本体のHDDやSSDからではなく、DVDやUSBメモリなどの外部メディアからOSを起動させること。

Firefoxの新しいマスコットキャラクターがかわいい

何気なくFirefoxの設定画面を開いたとき、かわいらしいキツネのキャラクターがいることに気づいた。

このキャラクターはFirefoxの新しいマスコットキャラクターで、Kitという名前らしい。

forest.watch.impress.co.jp

Firefoxのマスコットキャラクターといえば、フォクすけを思い出す。

foxkeh.jp

私はフォクすけはFirefoxの公式マスコットキャラクターだと思っていたが、どうも違ったようで日本限定のキャラクターみたい。

Firefoxには、Kitが発表される以前からいろいろなキャラクターが登場している。例えば、ツールバーをカスタマイズするときに謎のキャラクターが表示される。

これは明らかにキツネではないけど、一体何のキャラクターなんだろうか…？

また、現時点の最新バージョン（Ver.151）では接続エラー時にKitとは違うキツネのキャラクターが表示される。

以前は恐竜のようなキャラクターが表示されていたと思うが、どこかのバージョンから変わったみたい。

このように、Firefoxを使っているといろいろなキャラクターが表示される。「たかがキャラクター」と思うかもしれないが、こうしたキャラクターがたびたび画面上に出てくると親近感がわいてくる。ある意味、キャラクターの存在がFirefoxの特徴ともいえる。

もしかしたら、今後上記のキャラクターたちもKitに置き換わるのかもしれない。ただ、個人的にKitのデザインはけっこう好みなので、今後Firefoxを盛り上げてくれることに期待したい。

Windowsサンドボックスが起動できない場合の対処方法

Windowsサンドボックス起動時に、「Windows サンドボックス環境への接続が失われました。再接続しますか？」というメッセージが表示され起動できないことがあった。

再接続を数回押したが、変わらず同じメッセージが表示され起動できない。ただ、メッセージが表示されず正常に起動できる場合があったりと、私の環境では不安定な動作をしている。Windowsサンドボックスを一旦無効にして再度有効にしてみたが、変わらなかった。

なお、この症状は以下の環境で発生した。

• Windows11 Pro バージョン25H2
• CPU：Core Ultra 7 155H
• GPU：Intel Arc Graphics（CPU内蔵）
• メモリ：32GB

いろいろ試したところ正常に起動するようになったので、私が行った対処方法を簡単に書く。

対処方法

仮想GPU（vGPU）を無効化してWindowsサンドボックスを起動する。

デフォルトでは仮想GPUが有効になっているので、以下のように構成ファイル（wsbファイル）を作成し仮想GPUを無効化する。

<Configuration>
  <vGPU>Disable</vGPU>
</Configuration>

ファイルの拡張子を.wsdとして保存すると、以下のようなアイコンになる。今回は、「vGPU無効化」という名前の構成ファイルを作成した。

このアイコンを開くと、構成ファイルの内容でWindowsサンドボックスが起動する。

補足

デフォルトの構成について

Windowsサンドボックスの構成については、以下の公式ページが詳しい。

learn.microsoft.com

以下、公式ページよりデフォルトの構成を引用。

次のプロパティを使用して、最大容量が 4 GB の基本的なサンドボックスが起動されます。

• vGPU (仮想化 GPU): Arm64 以外のデバイスで有効です。
• ネットワーク: 有効です。 サンドボックスでは、Hyper-V の既定のスイッチが使用されます。
• オーディオ入力: 有効。 サンドボックスは、ホストのマイク入力をサンドボックスに共有します。
• ビデオ入力: 無効。 サンドボックスは、ホストのビデオ入力をサンドボックスに共有しません。
• 保護されたクライアント: 無効。 サンドボックスでは、リモート デスクトップ プロトコル (RDP) セッションでセキュリティ設定の強化は使用されません。
  プリンターのリダイレクト: 無効。 サンドボックスは、ホストとプリンターを共有しません。
• クリップボードのリダイレクト: 有効です。 サンドボックスは、テキストとファイルを前後に貼り付けることができるように、ホスト クリップボードをサンドボックスと共有します。

デフォルト以外の構成でWindowsサンドボックスを起動したい場合は、別途構成ファイル（wsbファイル）を作成して起動する。構成ファイルの書き方については、上記の公式ページで詳しく解説されているのでそちらを参照していただきたい。

仮想GPUについて

今回無効にした仮想GPUとは、簡単に言えばホスト側のGPUをサンドボックス側のGPUと共有する機能。以下、公式ページより引用。

vGPU

GPU 共有を有効または無効にします。

XML

<vGPU>value</vGPU>

サポートされている値:

• Enable: サンドボックス内で vGPU のサポートを有効にします。
• Disable: サンドボックス内で vGPU のサポートを無効にします。 この値が設定されている場合、サンドボックスはソフトウェア レンダリングを使用します。これは仮想化された GPU よりも遅くなる可能性があります。
• 既定値: この値は、vGPU サポートの既定値です。 現在、この既定値は vGPU が有効になっていることを示します。

公式ページにも記載がある通り、デフォルトでは有効になっている。なお、仮想GPUを無効にすると動作が遅くなる可能性があるとのこと。ただ、私が触った限りではそこまで動作の遅さは感じなかった。サンドボックス内で重い処理をすると影響があるのだろうか。

おわりに

バージョン25H2がインストールされた別のパソコンではこの問題は起きていないので、OSとGPUの相性の問題だろうか。なお、グラフィックスドライバを最新に更新しても同じメッセージが表示されたので、グラフィックスドライバの不具合ではなさそう。

仮想GPUを無効にすることで起動できるようになったので、根本的な原因は分からないがGPUが影響していると思われる。参考にどうぞ。

最近読んでみたいと思った技術書の話

私は最近、技術書を読むことから遠ざかってしまっている。これは、平日になかなか読む時間がないというのもあるが、私自身の怠惰の問題でもある。

技術書を読むことから遠ざかって気づいたのが、一度遠ざかってしまうと再度同じ本を読むことすら面倒になり、ますます読まなくなってしまうこと。ちょっとこれはまずいと思ったので、また技術書を読み進めることにした。なので、個人的に最近読んでみたいと思った技術書を紹介する。

インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン

インフラ/ネットワークエンジニアのためのネットワーク・デザインパターン　実務で使えるネットワーク構成の最適解２７

この本は以前から気になっていたが、初版が2015年とやや古いこともあり「そのうち改訂版が出るだろう」と思い放置していた。同じ著者の本では「インフラ／ネットワークエンジニアのためのネットワーク技術＆設計入門 第2版」のほうが有名で、（やや内容は難しいが）万人におすすめできる。私もこの本を持っており、ネットワーク知識の大部分はこの本から得たと言えるぐらいお世話になった。

それに対し、こちらは大小様々なネットワーク構成が載っている本で、ただ眺めているだけでも「こういうネットワーク構成があるのか」と勉強になる。ただ、情報量がとても多い上にある程度ネットワークについての知識を持っていることが前提の内容なので、読み進めるのがちょっとしんどいかも。

マンガ＋図解で基礎がよくわかる　情報セキュリティの教科書

マンガ＋図解で基礎がよくわかる　情報セキュリティの教科書

こちらも、以前から気になっていた本。以前は情報セキュリティ関係の本をよく読んでいたが、最近は読んでいないのであまり知識がアップデートされていない。ネスペシリーズでおなじみの著者が書いた本で、マンガに目が行きがちだが本文の解説も分かりやすい。

おわりに

他にも読んでみたい本はあるが、今回はとりあえず今の私が優先して読んでみたいと思った本を紹介した。この記事を書いていて思ったのが、読みたい本の分野に偏りがあること。ネットワークや情報セキュリティ以外の本も読んでみたい気はするが、あまりなじみがないせいか読んでみたいという内容が思い浮かばない。

これといって特にオチはないが、「この人はこういう本に興味があるのか」程度に思っていただければ。

ハイレゾ音源（最大384kHz/32bit）対応のUSBタイプC - 3.5 mmイヤホンジャック変換ケーブルを買った

ハイレゾ音源（最大384kHz/32bit）対応のUSBタイプC - 3.5 mmイヤホンジャック変換ケーブルを買ったので、簡単に書く。

買ったのは、エレコムの「MPA-C35DSMWH」という型番の変換ケーブル。価格は2,500円程度。

www.elecom.co.jp

以下、エレコム公式サイトより引用。

MPA-C35DSMWH音楽や映画も高音質で楽しめるPCM最大384kHz/32bitに対応したDACを搭載。デジタル信号・アナログ信号の両方に対応しています。 

「エレコム製で最大384kHz/32bit対応…？」と思った方は鋭い。通常、バッファローやエレコムといった大手メーカーのハイレゾ対応品は最大96kHz/24bit対応であることが多い。実際、エレコムには他に同様の変換ケーブルがあるが、そちらは最大96kHz/24bit対応となっている。

また、一般的にハイレゾ対応というと48kHz/24bit以上に対応していることを意味する。私の体感ではハイレゾ音源は48kHz/24bitもしくは96kHz/24bitのいずれかで配信されていることが多いので、最大384kHz/32bit対応というのは正直オーバースペック気味である。なぜこの変換ケーブルだけ最大384kHz/32bit対応なのだろうか？

なお、ハイレゾの定義については以下のサイトが詳しい。

www.jas-audio.or.jp

前置きが長くなってしまったが、実物がこちら。

パッケージには、ちゃんと「PCM最大384kHz/32bit」と書かれている。

見た目はごく一般的な変換ケーブル。

ケーブル部分はナイロンメッシュになっており、やや太めでやわらかいので耐久性は高そう。ちょっと端子部が大きめかな？

外観だけだと本当に384kHz/32bitに対応しているのか分からないので、サウンドのプロパティを開いてみた。確かに384kHz/32bit出力まで対応していることが分かる。

それにしても、この設定でここまで選択肢が出てくるのは初めてだな…。

音質について簡単に触れる。安価な変換ケーブルにありがちなホワイトノイズもなく、クリアに聞こえる。私の持っているウォークマン（NW-ZX707）と比べるとさすがにウォークマンのほうが上だが、2500円にしては音はいい方だと思う。

先ほどの出力設定をいじって、384kHz/32bit出力に変更してみた。なんとなく音の分離感が強くなったような気がするが、違和感がある。これは基本的にはデフォルトのままでいいだろう。なお、私は384kHz/32bitの音源を持っていないので残念ながらこの出力を生かすことはできない。

それにしても、エレコムという大手メーカーがこのようなちょっと尖った製品を販売しているのは意外だった。たまたま384kHz/32bit対応のDACが安く手に入ったのだろうか。384kHz/32bit出力は使わないにしても、音がクリアで取り回しもよさそうなケーブルなので今のところ満足している。