syghの新フラグメント置き場

プログラミングTipsやコード断片の保管場所です。お絵描きもときどき載せます。

Visual Studio 2022とF# Interactiveと.NET CLIテレメトリ

Windowsの標準スクリプト言語と言えばPowerShellですが、個人的にPowerShellの文法が好きではないので、普段はF#をスクリプト言語として使うということをやっています*1
F#は関数型言語ですが、純粋関数型言語Haskellほど窮屈な原理主義を強制するものではないものの、C#よりも厳格で副作用の少ないコードを書きやすいので、頭の体操がてらに「better C#」としてゆるく使っています。
そんな大層な使い方をしているわけではなく、.NETクラスライブラリを使ってファイルシステム正規表現検索するなど、現状ではちょっとした雑用の自動化にしか使っていません。
F#の対話環境「F# Interactive」は、C# Interactiveと同様にVisual Studioにも統合されているので、ちょっとしたコードを試すのに便利です。

sygh.hatenadiary.jp

VS2015では、インストール後に拡張子.fsxにVisual Studioが関連付けられ、さらにコンテキストメニューに「Run with F# interactive...」というコマンドが追加されていましたが、VS2022ではそういったことはありません。開発・実行環境のメインストリームが.NET Frameworkから.NET (.NET Core) に移ったことで、実行基盤であるCLRのバージョンが流動的になったことと関係しているのだと思います。
.NETではdotnetコマンドを使うことで、ビルドなどの.NETプロジェクトに関連する様々なタスクを実行することができるようになっていますが、dotnet fsiコマンドを使うことで、F# Interactiveを起動することができ、従来通り.fsxファイルを指定してスクリプトを実行させることもできます。
レジストリをいじってコンテキストメニューに従来の互換コマンドを追加することもできるはずですが、今後はコマンドラインから明示的に起動するほうがよいかもしれません。

learn.microsoft.com

.NET CLIテレメトリ

Visual StudioからF# Interactiveを最初に起動すると、以下のようなメッセージが出力されます。

Visual Studio の .NET Core の F# インタラクティブへようこそ。コードを実行するには、
  1. F# スクリプトから [Interactive に送信] (Alt+Enter または右クリック) を使用します。F# インタラクティブ プロセスでは、
     そのスクリプトに関連付けられている任意の global.json 設定が使用されます。
  2. 開始するには、Enter キーを押します。F# インタラクティブ プロセスでは、既定の設定が使用されます。
> 

ここでEnterキーを押してみると、以下のようなメッセージが続けて出力されます。

.NET 9.0 へようこそ!
---------------------
SDK バージョン: 9.0.306

テレメトリ
---------
.NET ツールは、エクスペリエンスの向上のために利用状況データを収集します。データは Microsoft によって収集され、コミュニティと共有されます。テレメトリをオプトアウトするには、好みのシェルを使用して、DOTNET_CLI_TELEMETRY_OPTOUT 環境変数を '1' または 'true' に設定できます。

.NET CLI ツールのテレメトリの詳細をご覧ください: https://aka.ms/dotnet-cli-telemetry

----------------
ASP.NET Core HTTPS 開発証明書をインストールしました。
証明書を信頼するには、'dotnet dev-certs https --trust' を実行します
HTTPS の詳細情報: https://aka.ms/dotnet-https

----------------
最初のアプリを作成するには、https://aka.ms/dotnet-hello-world を参照してください
最新情報については、https://aka.ms/dotnet-whats-new を参照してください
ドキュメントを探すには、https://aka.ms/dotnet-docs を参照してください
GitHub で問題の報告とソースの検索を行うには、https://github.com/dotnet/core を参照してください
'dotnet --help' を使用して使用可能なコマンドを確認するか、https://aka.ms/dotnet-cli にアクセスしてください
--------------------------------------------------------------------------------------

Microsoft (R) F# インタラクティブ バージョン F# 9.0 のための 13.9.303.0
Copyright (C) Microsoft Corporation. All rights reserved.

ヘルプを表示するには次を入力してください: #help;;

> val it: unit = ()

> 

出ました、MSによる個人情報の勝手な収集・送信癖。

learn.microsoft.com

How to opt out

The .NET SDK telemetry feature is enabled by default for Microsoft distributions of the SDK. To opt out of the telemetry feature, set the DOTNET_CLI_TELEMETRY_OPTOUT environment variable to 1 or true.

A single telemetry entry is also sent by the .NET SDK installer when a successful installation happens. To opt out, set the DOTNET_CLI_TELEMETRY_OPTOUT environment variable before you install the .NET SDK.

Data points

The telemetry feature doesn't collect personal data, such as usernames or email addresses. It doesn't scan your code and doesn't extract project-level data, such as name, repository, or author. ……

ドキュメントによると、一応ユーザー名やメールアドレスのような個人データは収集せず、ユーザーが書いたコードなどもスキャンしないと書かれていますが、どうなるか分かったものではありません。ネットワークを無駄に使われるのも気に入らないので、環境変数DOTNET_CLI_TELEMETRY_OPTOUTを設定して無効化します。
setxコマンドを使って設定する方法を紹介している人が多いですが、おなじみのシステムプロパティ(詳細設定)ダイアログのGUIからシステム環境変数またはユーザー環境変数を作成してもよいはずです。

最悪なことに、この.NET CLIテレメトリはデフォルトで有効化されてしまっており、環境変数を設定せずに.NET SDKインストーラーを実行すると、初回の利用データは必ず送信されてしまいます。
環境変数を設定しておけば、以後の利用データは送信されない動作になるはずですが、もしインストール時の初回の利用データも含めて一切送信したくない場合は、.NET SDKをインストールする前(.NET CLIツールを使い始める前)に環境変数を設定しておく必要があります。
以前Visual Studio 2019で.NET 5を使っていた頃は、テレメトリ機能のオプトアウトのために環境変数を設定した記憶はないのですが、当時気付いていなかっただけのようです。

Android StudioFirefoxなど、他の開発環境やブラウザでも利用データやクラッシュレポートなどを収集する機能はありますが、データを開発元に送信するかどうかは最初に必ずダイアログで確認をとるようになっています(オプトイン)。こういう機能をデフォルト有効のオプトアウト方式にするのはアカンでしょ。EUGDPRに違反してるんじゃねーの? 通報しようか?
昔からMSは汚い企業だったけど、さすがにここまで下劣ではなかったと思うよ。バルマーが失脚してインド人のサティア・ナデラがCEOになってから業績は好調のようだけど、なりふり構わないというか本当に無節操になったと感じます。どうもアイツは胡散臭くて好かんね。

*1:他にも広く使われているスクリプト言語の代表格と言えばPythonがありますが、Pythonは動的型付け言語の中でも特にハーネスの欠如した無節操な言語なので、自分はPythonも嫌いです。

Visual Studio 2015の完全アンインストール(ができなかったという話)

Windows 10とともに、Visual Studio 2015のサポートも2025-10-14(米国時間)に終了しました。手元のPCでは、OSのほうはWindows 11に移行済みですが、Visual Studioのほうはまだ2022に移行していませんでした。
そのため、まずはVS2015をアンインストールしようとしたんですが、コントロールパネルから「Microsoft Visual Studio Community 2015」や「TypeScript Tools for Microsoft Visual Studio 2015 1.5.4.0」「同 1.6.3.0」「同 1.7.4.0」を右クリックして「変更」や「アンインストール」を実行しようとしても、Visual Studioのスプラッシュスクリーンが数秒表示されるだけで、アンインストールできません。

「設定」→「アプリ」→「インストールされているアプリ」にて「変更」や「アンインストール」を実行した場合、UACダイアログ上の「詳細を表示」から、インストーラーのキャッシュがコピーされている場所が分かります。

"%ProgramData%\Package Cache\{<GUID>}" の配下に、"vs_community.exe" や "TypeScript_Full.exe" がコピーされています。<GUID> はおそらく最初にインストーラーを起動したときに自動生成されるもので、環境によって異なるはず。

コマンドプロンプトを管理者権限で起動し、上記ディレクトリにて /repair オプションを付けてインストーラーを起動してみましたが、やはり正常に動作しません。
以下のようにPowerShellを使って結果コードを取得してみましたが、00000000が返ってきていて、エラーコードも分かりません。

$result = Start-Process -FilePath "vs_community.exe" -ArgumentList "/repair" -PassThru -Wait
Write-Host $result.ExitCode.ToString("X8")

最終手段として VisualStudioUninstaller を使って大半のコンポーネントは削除できたものの、下記ログのように何度実行しても残るコンポーネントがいくつかあり、またコントロールパネルには前述の4項目が残り続けています。

github.com

C:\xxx\TotalUninstaller>Setup.ForcedUninstall.exe
The following bundles were detected on your system:
(Name: Microsoft Visual Studio Community 2015, Version: 14.0.23107.178, BundleId: 18973f44-fc03-4f49-966e-0873a033ec95)
(Name: Visual Studio 2015 Update 3 (KB3022398), Version: 14.0.25420, BundleId: 7a68448b-9cf2-4049-bd73-5875f1aa7ba2)
WARNING: This executable is designed to cleanup/scorch all Preview/RC/RTM releases of Visual Studio 2013, Visual Studio 2015 and Visual Studio vNext.
It should be used as the last resort to clean up the user's system before resorting to reimaging the machine.
Would you like to continue? [Y/N]
y
Uninstalling: C:\ProgramData\Package Cache\{18973f44-fc03-4f49-966e-0873a033ec95}\vs_community.exe
Bundle: Microsoft Visual Studio Community 2015 has been uninstalled with exit code: 0.
Uninstalling: C:\ProgramData\Package Cache\{7a68448b-9cf2-4049-bd73-5875f1aa7ba2}\vsupdate_KB3022398.exe
Bundle: Visual Studio 2015 Update 3 (KB3022398) has been uninstalled with exit code: 0.
Normal Visual Studio Uninstall completed.
Searching for stale MSIs and clean up stale MSIs.
3 stale MSIs found.  Uninstalling them.
Uninstalled LocalESPCui for ja-jp with exit code: 0. 2/3
Uninstalled LocalESPCui for ja-jp Dev12 with exit code: 0. 1/3
Uninstalled WCF Data Services Tools for VS 2015 JPN Language Pack with exit code: 0. 0/3
Deleting registry: SOFTWARE\Microsoft\VisualStudio\12.0
Deleting registry: SOFTWARE\Microsoft\VisualStudio\14.0
Deleting registry: SOFTWARE\Microsoft\VisualStudio\15.0
Deleting registry: SOFTWARE\Microsoft\VisualStudio\12.0_Config
Deleting registry: SOFTWARE\Microsoft\VisualStudio\14.0_Config
Deleting registry: SOFTWARE\Microsoft\VisualStudio\15.0_Config
Deleting registry: SOFTWARE\Microsoft\DevDiv\vs\Servicing\12.0
Deleting registry: SOFTWARE\Microsoft\DevDiv\vs\Servicing\14.0
Deleting registry: SOFTWARE\Microsoft\DevDiv\vs\Servicing\15.0

%Temp% の配下にログファイルが出力されますが、i000: Ux Startedという行を最後に、以降は何も記録されていません。

もともとWindows 10だった頃にインストールしていて、普通に使うぶんには何の問題もなかったのですが、システム上に何らかのゴミが残っていて正常なアンインストールを拒んでいるんだと思います。この状態に陥るとVS2015の再インストールもできなくなります。しかし今更サポート切れのVS2015のインストーラーのデバッグをするなど御免こうむりたい。そもそもVS2015はWindows 11には正式対応していないので、何が起きても不思議ではない。

若干気持ち悪いものの、とりあえずどうしようもないし、VS2017以降でおなじみとなったVisual Studio Installerのほうは正常に起動・動作するので、VS2015の残骸は放置してVS2022をサクッとインストールしました。.NET (C#/F#) とATL/MFC (C++) のデスクトップ開発環境を最低限構築するためのコンポーネントを選択して、10分程度でダウンロード&インストールが完了。やはりNVMe SSDは爆速ですね。

iPhoneからAppleCare+に加入できない場合はPCブラウザを利用する

前回の残件、機種変更後のiPhone 16の保険加入です。結局AppleCare+で貢ぐことにしました。しかも盗難・紛失対応プランの一括払い。何が起こるか分からない、それが野球人生。

sygh.hatenadiary.jp

Appleバイスは、購入時だけでなく購入後1か月以内であれば、追加保証サービスのAppleCare+に加入することができます。
AppleCare+はデバイスごとに紐づいているので、機種変更時に旧端末の加入期間が残っていたとしても、新端末では別途料金を支払う必要があります。
盗難・紛失対応保証の有/無、月額払い/購入日から2年間保証分の一括払いの組み合わせで合計4つのプランがありますが、2年以内に端末を手放すようなことでもなければ一括払いのほうがお得です。
仮に2年以内に手放すとしても、AppleCareに入っていたほうが、売却時に価値が上乗せされるそうです。まあ俺は売らないけどね。

本来はiPhone上でも設定アプリからAppleCare+に加入できるはずなのですが、新しいiPhone 16でクレジットカード情報の入力後、請求先情報(住所や電話番号など)の入力時にどうしても検証エラーが出て先に進めない現象が出ました。

結論としては、PCのブラウザを使ってApple公式サイトにログインし、Apple Account(旧称Apple ID)設定ページから https://getsupport.apple.com/topics に飛んで、「サブスクリプションと購入」→「AppleCareと製品保証」でクレジットカード決済することにより無事加入できました。デバイスに保存されている請求先情報と、サーバーに保存されている請求先情報に乖離があるとこの現象が起きてしまうようです。
iPhoneのブラウザ(Safari)から公式サイト経由でアクセスした場合、結局設定アプリのAppleCare+加入画面に飛ばされてしまうので、この現象が発生してしまった場合、おそらくPCもしくは別のデバイスが必須ということになります。

ちなみにAppleCare+に加入する際は、デバイスの健康状態をチェックする必要があり、手続きの途中でWebページ上にQRコードが表示され、iPhoneのカメラで読み取って診断プログラムを起動する必要があります。診断処理自体は短時間で終わります。

色々な手間を考えると、AppleCare+に加入することを最初から決めているのであれば、購入のタイミングで加入しておいたほうがよさそうです。もし購入時にAppleCare+に加入しておらず、加入前に故障させてしまった場合、診断ではじかれて加入することができなくなってしまうはずです。

ところで、今や多くの一般人はPCを持たずスマートフォンだけで生活しているとかいう話を聞きますが、こういったトラブルのときにスマートフォン1台しか持っていない場合は詰んでしまうのでは? 怖すぎでしょ。せめて安物でもいいからノートPCくらいは持っておいたほうがいいと思う。

自分はPCの更新作業中やトラブル時はスマートフォンで情報収集することもあるし、その逆にスマートフォンの機種変更時やトラブル時にはPCで情報収集することもあります。もしどちらかがインターネットに接続できない状態に陥っても、もう片方で情報収集できる手段を用意しておけば安心です。

あと自宅にネット環境がない人はどうしているんですかね? まさかキャリアのモバイル通信やフリーWi-Fiだけで情報収集しているんですかね? つらくないですか?
クルマを持っている人は車載Wi-Fiという手があるみたいですが、一定時間停車していると切断されてしまうんですよね? つらくないですか?

iPhone 8からiPhone 16への移行

家庭(実家)の事情やWindows PCの更新などでゴタゴタしていて余裕がなかったことから、iPhone 8のままずるずると使い続けていました。Touch IDの利便性や物理ホームボタンの単純明快さ*1、ほぼ片手で操作可能な筐体のコンパクトさが捨てがたかったということもあります。
しかし、Lightningコネクタの摩耗による接触不良やバッテリー寿命が限界に来ていたこと(新品の購入時から一度も交換していないので最大容量が70%台に落ちている)、そして最大の問題としてiOS 16のサポートを終了するアプリが出てきて使い続けるわけにはいかなくなったことから、とうとうiPhone 16無印に移行しました。iPhone 16自体は去年から狙っていて、iPhone 17がリリースされて型落ちになり値下げされるまで待っていました。128GBモデル以外は終売となっていますが、ストレージはそれほど使わないので十分です*2*3

iPhone 5iPhone 8のときはよく分かっていなかったので、キャリアの店頭で機種変更作業をやってもらいましたが、当然キャリアで買うと端末価格自体も高いし、今回データ移行作業は完全に自分でコントロールしたかったので、SIMフリー端末を自分で購入して、全データの移行後に物理SIMカードを差し替えています。
ちなみにiOSのUI言語は普段から日本語ではなく英語にしているんですが、Apple製品特有の用語が分かっていれば移行作業中も大して困ることはないです。

iTunesとクイックスタート

もともとiTunesにより作成したローカルバックアップデータを使って移行する予定でしたが、アホなことにiTunesバックアップからの復元時に入力を求められる暗号化のパスワードが分からなくなってしまい*4、結局普段の仕事のデバイス移行作業でもよく使っているクイックスタートにしました。
結論から言うと、クイックスタートでOS設定もアプリもユーザーデータも問題なくすべて完璧に移行でき、最後にSIMカードを旧端末から抜いて新端末に差し替えるだけの簡単な仕事でした。数日かかったWindows PCの移行作業に比べると、本当にあっけなく1時間程度で終わりました(iTunesでバックアップや復元を試行錯誤していた時間は除く)。iOS 16.xからiOS 18.5へのギャップがあるにもかかわらず、互換性のある設定はうまく移行されていました。すでにApp Storeに公開されていないアプリはインストールされず、またSafari拡張機能としてインストールしている広告ブロッカーアプリ (AdGuard) の設定を一部有効化する必要があったくらいです。

クイックスタートは旧端末と新端末の間でBluetoothWi-Fi*5を使ったPeer-to-Peer通信によって設定やデータをコピーする機能です。写真やドキュメントだけでなくアプリデータも完全に移行できます。

移行の途中でパスコードによる認証が何度か必要になりますが、iCloudにバックアップしているデータを併用して復元する必要がある場合、iCloudのセキュリティコード(PIN)を聞かれることもあるようなので注意が必要です。

LINEの移行もクイックスタートで可能(ただし事前準備が必要)

移行を躊躇していた理由の1つが、LINEとかいう例のSNSアプリです。昔連絡用に要求されたので仕方なく使っていたことが一時期あったものの、使わなくなってアンインストールしましたが、現在家族との連絡に使っている関係上、再び仕方なくインストールしていました。
コイツのユーザーデータ(特にトーク履歴)の完全な復元には、たとえiPhoneからiPhoneに移行する場合であっても、MacあるいはiTunes for Windowsが必須で、クイックスタートでは完全な復元はできないという情報もありましたが、それは昔の話らしく、現在は改善されていて、事前準備をしておけばクイックスタートでも完全に移行できるようです(ただしLINEのバックアップデータをiCloudにすべて保存できる空き容量があるという前提)。そもそも、iOS間/iPadOS間やAndroid間であっても引き継ぎ・移行できないデータがあるというのはおかしな話だと思いますが、基本無料のアプリで貧乏人が文句を言うのは筋違いかもしれません。手厚い保証や機能が欲しいヘビーユーザーはプレミアムプランの会員費を払えということだと思います*6

公式サイトの手順に従って、事前に旧端末のLINEアプリ内でアカウントに紐づけるメールアドレスやパスワード、バックアップPIN*7の設定をしておき、トーク履歴のiCloudへのバックアップを実施した後、アカウント引き継ぎ (Account transfer) モードをONに設定しておけば、後は普通にクイックスタートで移行するだけです。
これらの情報は新端末でLINEアプリを起動し、アカウントやデータを引き継ぐときに必要となるので、忘れずに設定しておく必要があります。

2025年11月以降はLINE 13.20以前のサポートが終了し、まともに動作しなくなる(起動はできても肝心の通信ができなくなる)ので、それまでにLINE 13.21以降にバージョンアップしなければならないという明確な期限があります。
もともとiOS 16.xではLINE 15.7までは使えたはずですが、手元のiPhone 8でLINE 13.5.1のまま放置していたところ、App Storeで更新できなくなっていました。
2025年3月以降はLINEのiOS 16サポートが終了したせいで、iOS 16に対応していた最後の旧バージョンもApp Storeでダウンロードすることができなくなってしまっているようです。
iPhone 16(出荷時の時点でiOS 18.x)への移行によって、LINEを無事15.16.1まで上げることができました。

Androidと違って、Appleの旧デバイスサポートはかなり長期に渡り、最新バージョンのOSがインストール可能というわけではないものの、最終サポートOSにおけるセキュリティパッチの提供という観点では、サポートサイクルがWindows OSの10年並みに長いことになるのですが、サードパーティ製のアプリはどんどん足切りをしてしまうのが悲しいところです。AndroidiOS/iPadOSは機能やAPIセットの追加・仕様変更および非推奨化が激しく、OSも端末も毎年新しいバージョンが出るので、開発者としてはいつまでも古いデバイスや古いOSのサポートをし続けるわけにはいかないというのは分かるのですが、せめて古いOSに対応する最後の旧バージョンをインストールできるようにしてくれ。

今後

iTunesでは暗号化せずにローカルバックアップをとることもできますが、iOSのHealthアプリやLINEのデータなどをiTunesでバックアップ&復元するには暗号化が必要となります。しかし、もし暗号化のパスワードを忘れてしまうと復元に使えなくなります。そうなると暗号化パスワードリセットのためにOS設定をリセットし、バックアップを再作成しなければならず、旧パスワードで作成された以前のバックアップデータは一切使えなくなってしまうので、いざというときのために今後は暗号化のパスワードを忘れないようにしたいものです。

iPhone 17以降は物理SIMが廃止されて、eSIMに一本化されているようですが、次の機種変更はずっと先のことなので、今後の移行時にどうするかはまたそのとき考えることにします。

端末の保険はもともとキャリアのAppleCare+相当サービスに加入していましたが、iPhone 8と比べてiPhone 16の利用料は高くなるので、別の保険会社を利用することも検討中。AppleCare+は端末ごとに紐づけられているので、旧端末のほうはもう使わないのであれば解約する必要があります。

あとメインの充電手段をどうするかも考える必要がありそうです。iPhone 8の時点でワイヤレス充電(Qi規格)に対応していましたが、有線よりも発熱しやすいらしく、本体に負荷がかかりそうだったので見送っていました。しかし有線だと毎日の繰り返し利用でコネクタが確実に摩耗してしまうというデメリットがあり、それはLightningもUSB-Cも変わらない*8ので、今後はワイヤレス充電をメインにしたほうがよいのかも。MagSafeにするか、それともQi2にするか検討中。

www.itmedia.co.jp

ところでApple純正の有線ケーブルってなんであんなに首の部分(ケーブルと端子カバー部の間)が弱そうなんですかね? 一般的なサードパーティ製品と比べて、見るからに曲げや引っ張りに弱そうで、被覆も劣化しやすく、構造も材質も意図的に長持ちしないように作っているとしか思えません。

*1:もともとホーム画面やアプリ切り替え画面に関するシステムUIのジェスチャーナビゲーション操作はAndroidiOSもファジーなところがあり、直感性や確実性に欠けていて嫌いなので、仕事で使っているAndroid端末でもすべて3ボタンナビゲーションにしています。各アプリ内の操作に関しては、大きめの端末を片手で操作する場合はボタンよりもジェスチャーのほうが便利なときもありますが。

*2:iPhoneでゲームをするユーザーは内蔵ストレージ容量が多いほうがよいと思いますが、自分はPCゲームにしか興味がなく、モバイル端末ではゲームをしません。カメラは使いますが、もっぱら静止画のみで、動画は興味ないです。

*3:母艦がWindowsなのにiPhoneを使っているのは奇特なパターンだと思いますが、もともとAndroid端末の出来がどのベンダーもひどくてサポート期間が短かった時代(いわゆるオンボロイド時代)にスマートフォンを使い始めたので、当時の自分の選択肢としてはiPhone以外にありえませんでした。Android端末は選択肢が豊富でカスタマイズ性が高いし、今はAndroid端末の性能も同一価格帯のiPhone以上に上がっていて、サポート期間も伸びていますが、iOSは標準アプリの出来がよいこと、またiOS/Android間のデータ互換性は完全ではないことから、今更乗り換えるつもりはありません。価格に関してはiPhoneだけでなくAndroidも全体的に上がっており、全部円安のせいです。

*4:自分で設定していた記憶は全然ないのですが、忘れているだけかもしれません。

*5:Bluetooth帯域幅が狭いので、主にP2P接続確立用の小さな情報をやりとりするために使われ、データ転送を高速化するためにWi-Fiも併用されます。

*6:ソフトバンクのユーザーは自動的にLYPプレミアムが利用できるので、LINEアカウントと連携すればLINEのプレミアムプランも追加料金なしで使えるらしいです。対価としては個人情報を売り渡すという前提になります。

*7:このバックアップPINは、前述のクイックスタートにおけるiCloudセキュリティコードとは別物です。

*8:仕事で使っているAndroid端末も、デバッグのためにUSB-Cケーブルの抜き差しを繰り返してきたものは接触不良を起こしやすくなっています。一応Android 11以降はWi-Fiによるワイヤレスリモートデバッグという選択肢もあり、今はそちらをメインのデバッグ手段にしているんですが、有線と違って自動で認識しない(あるいは認識まで時間がかかる)ことも多いため、adb connectのコマンドラインからIPアドレスとポート番号を手動入力する必要があったりしてストレスが溜まります。本体側の端子の摩耗を減らすためにケーブル側の端子を擦り減りやすい材質にするとかして欲しい。

Windowsの品質低下問題に思うこと

Windows 10のサポート終了が10月14日に迫っていますが、世界的に見てもWindows 11への移行は全然進んでいないですね。人気の高かったWindows 7のサポートが2020年1月に終了する直前、2019年12月の時点でWindows OSのバージョン別シェアに占める7の割合はそれでも25%程度に減っていましたが、今回Windows 10のシェアは2025年8月の時点でまだ45%以上もあり、9月の時点で40%です。Windows 7/8.xからWindows 10へのアップグレードのときのMSによるゴリ押しキャンペーンも大概で、いつの間にか勝手にアップグレードされてしまったユーザーもいたようですが、Windows 7/8.xからWindows 10への移行が比較的スムーズに進んだのは、無償アップグレードパスが存在したことのほか、Windows 10は7/8.xと比べてハードウェア要件はほとんど変わらなかったことが最も大きな要因だと思われます。今回もWindows 10からWindows 11への無償アップグレードパスはあるものの、移行が全然進んでいない理由として考えられるのは、Windows 11は古いハードウェアへの対応をバッサリ打ち切ったことのほか、いまだにOS自体の品質が低く安定しておらず、特に企業ユーザーにとって使いにくいことも関係しているのではないかと推測されます。

仕事の開発環境でもしばらく前から11を使っており、自宅の個人PCもとうとう11にアップグレードしましたが、10のほうが遥かに使いやすい。11はマジモンの低品質クソOSです。あらゆる場面でイライライライラさせられます。10も初期設定はグダグダで、様々なポイントをカスタマイズ・取捨選択してようやく使い物になりますが、それでも各種設定変更を駆使してOS標準でカスタマイズできる余地があったという点で11とは雲泥の差です。11はそういった選択肢が極端に狭い(あるいは選択肢そのものがない)ことが問題のひとつなんです。

そのような問題点の多さから、11はVistaの再来とか揶揄されることもありますが、ハッキリ言ってVistaに対して超絶失礼ですね。全然分かっていない。Windows Vistaもリリース当初(2006年~2007年)はバグが多かったものの、2008年にSP1が、そして2009年にSP2がリリースされ、その頃にはかなり安定していました。Vistaと11では問題の性質が大きく異なります。

Windows Vistaとは何だったのか

Windows XP(内部バージョンNT 5.1)の後継OSとして開発されたWindows Vista(内部バージョンNT 6.0)ではOSカーネルが大幅に再構築され、MinWinと呼ばれていました。のちにWindows 7(内部バージョンNT 6.1)でも発展形として軽量化されたバージョンのMinWinが搭載されました。Vistaも当時としてはハードウェアの要求スペックが高く、XP世代の低スペックPCでは満足に動作させることはできなかったものの、デスクトップPCの場合はメモリ増設やグラフィックスカードのアップグレードだけでどうにかなるものでした。Win32 APIの代替となる予定だったWinFX(のちの.NET Framework 3.0)が迷走したせいでリリースがかなり遅れてしまったのですが、最終的にWin32 APIは第一級市民のまま残りました。
OSカーネルの安定性やセキュリティレベルの向上はXPの比ではなく、Vistaで新しく搭載されたWDDM/DXGIやUACには明確なビジョンと方向性があり、いずれも現在まで続く重要基盤となっています。
UACの影響でシステムディレクトリへのアクセス権限がなくなったことで動作しなくなってしまったアプリケーションもありましたが、それはもともとアプリ側が無作法な設計になっていたからであり、ほとんどのアプリに対して有効な救済策としてVirtualStoreへの自動的なリダイレクトによってそのまま動作できるような仮想化の仕組みも用意されていました*1Unix系OSの厳格な権限管理と比べれば、今でもWindowsはぬるま湯です。
従来のグラフィックスAPIであるGDIはDirectXの基盤 (DXGI) 上に再構築されたことでハードウェアアクセラレーションが効かなくなり、パフォーマンスが低下してしまったという問題点もありましたが、のちに7で改良され、GDIのハードウェアアクセラレーションも部分的に復活しました。デスクトップウィンドウマネージャーに統合された視覚効果であるWindows Aeroも無駄に派手な部分はあったものの、DirectX (Direct3D 9Ex) 経由でGPUを駆使した美麗で滑らかなデスクトップレンダリングや、爽やかで近未来的なシステムサウンドは新しい時代の幕開けを感じさせてくれるものでした。
同時期に展開されていたコンシューマーゲーム機のXbox 360よりもグレードの高い3Dグラフィックス機能を持つ新世代のAPIとしてDirectX 10 (Direct3D 10) を搭載したことも評価できるポイントです。DirectX 10のAPI設計の基本はDirectX 10.1/DirectX 11にも受け継がれることになり、GeForce 8のようなDirectX 10対応のGPUで採用された統合型シェーダーアーキテクチャの設計はGPGPUの発展にも寄与しました。最終的にPlatform UpdateによってWindows VistaにもDirectX 11などの強力なAPI群がバックポートされたことにより、Windows 7との互換性も高くなりました。
64bit版のOSがコンシューマー向けのエディションも含めて一般的に提供されるようになったのもVistaからです。XPにも64bit版があったものの、内部バージョンがNT 5.2であり、つまりカーネルWindows Server 2003ベースで、どちらかというと企業ユーザー向けに展開された製品でした。

これだけ盛りだくさんの機能を搭載していればバグが頻発してもおかしくないですが、末期は十分に安定させていました。これまでWindowsポンコツ駄作バージョンと傑作バージョンが交互にリリースされていると言われていますが、Vistaがなければ7もなかったわけで、実際には隠れた傑作OSであり、個人的にはその名(眺望、展望)に恥じない意欲的な先進性を高く評価しています。Vistaで大きな問題となっていたのは、OSそのものというより、UACなどによる内部的な仕様変更が大きすぎて、従来のアプリケーションが追従できていなかったことのほうですね。UACの制約は7以降にも引き継がれているので、特に産業系の現場ではXPの延長サポート終了後もオフライン環境限定とはいえXPが使われ続けていました。もともとWindowsの権限まわりはゆるゆるで、アプリが好き勝手にできすぎてしまうことからセキュリティホールの温床であり、インターネット常時接続時代には大ナタを振るって根本からバッサリ変えていかない限り、もはやどうしようもなくなっていたことは確かです。

再びWindows 11

一方、Windows 11は今どうなっていますかね。Windows 10/11には、従来のサービスパック相当の定期的大型アップデートとして「機能更新プログラム」が提供されていますが、2024年10月にリリースされたWindows 11 24H2はWindows 10/11の中でも史上最悪と言える不安定さを誇るクソアップデートだそうです。いつまで経っても致命的なバグのオンパレードで、パッチがリリースされるたびにモグラ叩きのように新たな致命的バグが毎月のように出てくる有様です。ついにはPCを起動させなくするためにBIOSを破壊するウイルスのような動作*2まで始める始末。自分も開発者の端くれなので、100%完璧で不具合の一切ないソフトウェアなど幻想にすぎないことは当然理解していますが、いくらなんでも今のWindowsはひどすぎる。つまらん機能追加やUIの改悪(≠改善)にばかり熱心で、リソースの大半がもっていかれているせいで、システムコンポーネントに関してまともな知見のある連中が今はもういなくなっているんだろう。
そして個人情報を窃取するだけに飽き足らず、ご丁寧にユーザーファイルの勝手なロックあるいは削除までしてくれる公式ランサムウェア・OneDriveを搭載した今のWindowsは理想も何もなく、ただただ悪意に満ちています。マジで邪悪以外の何物でもない。Proエディションのユーザーは回避策がありますが、Homeエディションのユーザーは全員人柱になるという選択肢しかありません*3

note.com

邪悪な機能といえば、公式スパイウェア・Recallも猛反発をくらってオプトイン(デフォルトで無効)になりましたが、この先オプトアウト(デフォルトで有効)にしてきやがる可能性は非常に高いとみています。あるいは、ユーザーに知らせないだけで勝手に裏で盗撮してMSのサーバーに送信し始める可能性もありますね。気持ち悪すぎ。Windowsのネットワークパケットはサードパーティ製ツールで監視することはできるものの、偽装することだってできるはずです。Windowsプロプライエタリだからやろうと思えば何でもできる。今のMSはそのぐらいやりかねないし、もう全然信用できなくなっています。もはやバックドアが仕込まれている中国企業製品となんら変わりありません。

news.mynavi.jp
cloud.watch.impress.co.jp
gigazine.net
adguard.com

ちなみにWindows 10も22H2までは年2回程度の機能更新プログラムで頻繁に増改築を繰り返していて、その適用のたびに余計なシステム変更や設定リセットが入ってイライラさせられていました。Windows 10 October 2018 Update (1809) では一部環境においてユーザーファイルを勝手に削除する致命的なバグもやらかしています。とはいえ、現在のように毎月のセキュリティ更新プログラムごときで文鎮化を招くほどの致命的なバグをボロボロ出すようなことはなかったと思います。鬱陶しい挙動でムカつくクソOSに成り下がったWindows 10ですが、それでも22H2以降はようやく落ち着いたし、クリエイティブアプリやゲームのために今日まで使い続けてきました。
なお、Windows 10以降はWindows Updateの仕組みが大きく変わり、勝手にWindows Updateを実行して更新プログラムをインストールするだけでなく、ユーザーの意思を無視してOSの再起動までする邪悪な挙動が仕込まれ、作業データ損失などの大迷惑を被ったユーザーも多かったと思います。あの手この手で未完成クソ品質の自己満足オナニー機能更新プログラム*4を半強制的にインストールさせようとするMSのやり口の汚さに虫唾が走る毎日でした。Windows Updateのタイミングをある程度制御可能なProエディションであっても回避できない部分もあります。特に厄介なものとして、UpdateOrchestratorというタスクグループがあり、自分はPCが夜中に休止状態から勝手に復帰する現象にイライラさせられていました(実際には過去の話ではなく、UpdateOrchestratorはWindows Updateのたびに仕様が変わるため、定期的に対策の更新が必要となり、現在でも未だにイライラさせられています)。UpdateOrchestratorを設計したMSのエンジニアどもは地獄に落ちて欲しいですね。
唯一Windows 11で良くなった点と言えば、Windows 8.1までのようにインストールする更新プログラムやコンポーネントを個別に選べるようになったことでしょうか。というかこれはWindows 10がおかしかっただけであって、ようやく元に戻ったというだけの話です。

sygh.hatenadiary.jp

そして他のOSと比べると、WindowsのUIデザインの一貫性のなさが際立ちます。
macOSは癖が強いけれど、Windowsと違ってUIデザインに一貫性やポリシーがあり、メジャーバージョンアップ後でも古いバージョンを使っていたユーザーはアナロジー(類推)がだいたい通用するため、戸惑う場面は比較的少ないです。自分は信者ではないので、Appleの方法論やブランディングを無条件で賞賛するつもりはないし、macOSiOSは使う人を選ぶ道具であることは確かですが、OSとハードウェアとの垂直統合はMSのSurfaceGoogleのPixelとはまるで比較にならないレベルで完成されており、地味ながらも画面要素の隅々までプロフェッショナルのこだわりや矜持を感じさせるつくりになっています。
一方、Microsoftは誰もが慣れ親しんでいたWindowsアイデンティティとも言える伝統的なスタートボタン・スタートメニューを、Windows 8で廃止して総スカンをくらいました。というのも、代替のスタートスクリーンがあまりに未完成・中途半端・機能不全で分かりにくく、デスクトップにモバイルの作法を無理やり持ち込んだ挙句、結局使い勝手を完全に低下させただけだったからです。モダンUI(タイルUI)のシンプルなスタイル自体はそれほど悪いものではなく、またWindows 8はシステムの基盤となるWin32 APIには強力な機能追加がなされていて、COM/.NETで得られた知見を昇華させて綺麗なオブジェクト指向ベースで設計され、名前空間で分割整理されたモダンなWinRT APIも搭載していたのですが、それは開発者のみが知っていることで、OSのUIデザインとしては完全に誰もが認める失敗作です。8.1で申し訳程度にスタートボタンだけ復活させてお茶をにごし、結局10でスタートメニューも復活させたのですが、11でまたしても改悪しました。タスクバーやエクスプローラーも細かいバグや機能不全・改悪が多く、Windows 10までのほうが遥かに使いやすいです。特に11のタスクバーはクソofクソ。歴代最低と言っても過言ではない。冗談抜きで9x系のほうがマシなレベル。
こういったMSのUI/UXの一貫性のなさは昔から批判されていました*5

www.itmedia.co.jp

Windowsをよく知らない初心者や、たいして使い込んでもいないライトユーザーからすれば違いは分からないでしょうが、長年使ってきたパワーユーザーやエンジニアの視点から見れば、Windows 11がWindows 10に比べて弱体化していることは明白です。ProエディションですらWindows 10よりもコントロール性やカスタマイズの自由度が低下していることがマジで許せない。

japan.zdnet.com

以上の点からも、Vistaと11を同一視する連中は、実際にはVistaをロクに使ったことがないただのエアプ勢だということがよく分かりますね。

品質ガタ落ちの原因の1つはAI(笑)への傾倒

MSは最近AI(笑)にうつつを抜かしていて、すでにプロダクトコードの一部をAI(笑)で自動生成しているらしいけど、最近Windowsの品質低下が著しいのは多分AI(笑)への依存の加速が原因のひとつだと思いますね。設計・実装工程よりもテスト工程の自動化にこそ活用してバグ検出率を上げろよな。AIコーディング(笑)はその場しのぎのクソコードを大量生産して誤魔化すのには向いているかもしれませんが、自動生成されたコードをノーチェックで使っている脳死の連中がいる限り、品質の向上には役立たないどころか害悪でしかありません。そもそも現在のWindows 11は、古いハードウェアへの対応やWindows 10まで存在していた有用な機能を相当切り捨てたくせに、無駄にUIを変えたりエンドユーザーの個人情報をビッグデータとしてかすめ取るための余計な機能ばかり増やし続けたりしているせいでコードベースが異常に膨れ上がってしまっています。基礎を固めるためにはテストが不可欠ですが、基本的なWin32/WinRT APIIMEのような重コンポーネントすら挙動をデグレードさせているケースが多く、肝心のAPIや基本機能のリグレッションテストすらロクに実施していないことがうかがえます。実際にWin10でまともに動作していたAPIがWin11でぶっ壊れているということはよくあり、仕事でもMSに不具合報告しています。こんな有様でエンジニアのリストラを進めるのは逆効果であり、自ら首を絞めているようにしか見えません。
gigazine.net

Windowsカーネル実装に使われているのは主にC/C++/Rustですが、現在の生成AIはC/C++のコーディングには不向きだそうです。

gigazine.net

C/C++はもともと統合開発環境IDE)と相性が悪く、特にGUIアプリケーションプログラミングをC/C++でやろうとするのは最悪の選択肢です。JavaC#を使う場合と比べて、RADなどの支援がほとんど期待できません。
マシンの側に近いC/C++のような下位レベル言語のコード生成がAI(笑)にとっては不得手で、人間の側に近いPythonのような上位レベル言語のコード生成のほうが得手というのは皮肉なものですね。中間に位置するJavaC#はどうなんでしょうか。
もっとも、JavaC#のようなバランスの良い静的型付け言語のハーネスに慣れている自分としては、動的型付け言語の中でも最悪レベルでハーネスが欠如しているPythonのいい加減さが大嫌いです。Pythonは学生やスタートアップ企業が陳腐化上等でその場しのぎの使い捨てコードを書くのには適しているかもしれませんが、所詮は大規模開発を想定していない子供だましのオモチャみたいな言語です。Pythonで書かれたコードは、吐き気がするレベルで可読性やメンテナンス性が最悪になります。Pythonで書かれたコードそのものが翌日には陳腐化するゴミであり、そのためPythonで書かれたコードは少ないに越したことはありませんが、さらに生成AIでゴミを自動的に大量生産しようとするなんて狂気ですね。

WindowsはOS本来の役割に立ち返るべき

Windowsの最も良いところというのは、他のプラットフォームに比べてアプリケーションの後方互換性が異常なまでに高いということです。Windows 95で導入されたWin32 APIが、増改築を重ねながらもほぼそのままの形で維持されており、これを使って開発されたアプリケーションがずっと動作できるように互換性が保たれています。一部の古いDirectX APIは64bit版の実装が提供されず、WoW64によって32bit版のみが提供されているというものもありますが、Windows 9x(95/98/Me)の時代に作られたゲームですら普通に動作するものも多く、Windowsの互換性がいかに高いものであるかを実感できます。
ちなみに32bitシステムにまつわる時限爆弾として2038年問題があり、Appleはすでに32bitを完全に切り捨ててしまいましたが、32bit版のWindowsアプリケーションはWoW64がある限り、ギリギリまで使える可能性が高いです*6
自分が嫌々ながらもWindowsを使い続けている理由はまさにこのアプリケーション互換性の高さにあります。しかしMSがリグレッションテストをまともにやらなくなり、APIがどんどん壊れていけば、その大前提も崩れてしまうというわけです。
OSというのは本来アプリケーションを動かすための実行環境であって、裏方に徹するべきです。Windowsがユーザーの個人情報を窃取するためのマルウェアスパイウェアランサムウェアに成り下がっている現状に危機感をおぼえています。

*1:互換性をバッサリ切り捨てるAppleだと、こうはいかなかったと思います。

*2:M/B上のデータを破壊して復旧を困難にしてしまったという点で、ストレージ上のデータを破壊するタイプのウイルスよりタチが悪いかもしれません。

*3:一般ユーザーであっても、更新プログラムを受け取るタイミングを延期・制御できず、強制的にインストールさせられるHomeエディションを使うのはやめたほうがいいです。実験台にされるだけです。多少高くてもProエディションを使いましょう。グループポリシーで更新プログラムをかなり延期することができ、ドライバーやファームウェアの更新も阻止できるので、人柱にならずに済みます。

*4:特に2017年のCreators Update(笑)についてきた標準アプリはことごとく中途半端で壮大なゴミでした。もう誰も覚えていないと思うが、アレを実際にクリエイティブな作業に使っていた奇特な人はいないでしょ。

*5:実際には、MSのあらゆる製品がWindowsのような余計な改悪をしまくっているというわけではなく、順当にバージョンアップを重ねているまともな製品もあります。例えばVisual Studioはプロジェクトウィザード、ドッキングウィンドウやコードエディタータブといった基本的な画面構成や操作性が2005でいったん完成の域に到達し、2010でWPFベースになり、2012以降はスキンがモダンUIに変更されたものの、UI/UXの本質的な部分はほとんど変化していません。MS Officeと違ってリボンUIなどは採用せず、2022でも伝統的なメニューとツールバーの構成です。

*6:Win32 APIの時刻ライブラリやデータ構造自体は2038年問題を回避できるように設計されているので、アプリケーションがMSVC 8.0以降のCRTを使って実装されているか、もしくはMSVC 7.xまでの古いCRTの時刻ライブラリを使わずにWin32 APIだけを使って実装されていれば、WoW64がある限り2038年以降も使える可能性があります。

パーティションのMBR→GPT変換とWindows 11へのアップグレード作業

マザーボードを交換した後、なかなか作業残件を片付けるためのまとまった時間がとれなくて後回しにしていましたが、Windows 10のサポート終了も迫ってきたため、とうとう個人PCをWindows 11に移行しました。

sygh.hatenadiary.jp

もともとWindows 8Windows 8.1Windows 10とアップグレードしてきていましたが、OSをインストールしていたHDDのパーティションが旧形式のMBRだったので、そのままではWindows 11にアップグレードすることができず、最後の障壁となっていました。
OSのクリーンインストールをするのはいくらなんでも面倒すぎるので、MBR形式をGPT形式に変換し、UEFI/セキュアブートを有効化できるようにすることにしました。
ただし、MBR形式やSATAドライブを利用する場合、マザーボードのCSM(Legacy BIOS)を有効化しておく必要があり、一方GPT形式を使ってUEFI/セキュアブートを有効化するにはCSMを無効化する必要があるため、手順を誤るとOSが起動できなくなって詰んでしまいます*1。要するにSATAドライブ上で直接MBR→GPT変換をかけてはいけません。

  1. まずWindows 10のインストールされたSATAのHDDを、MBR形式のままNVMeのM.2 SSDに完全クローンする。
  2. 誤操作防止のため、クローン元のHDDのみを取り外す(SATAケーブルだけ外す形でもOK)。
  3. MS謹製の公式ツール mbr2gpt を使って変換する。
  4. 次回起動時にM/BのCSMをBIOS/UEFI画面で無効化し、UEFI/セキュアブートを有効化する。
  5. Windows 11にアップグレードする。

という手順を踏む必要があります。

ストレージのクローン

  • 登場人物
    • SATA内蔵HDD: Western Digital Redの1TB版 (WD10EFRX-68PJCN0)
    • 外付けHDD: BUFFALO HD-PCFU3の2TB版 (HD-PCF2.0U3-GBD)
    • NVMe内蔵SSD: WD BLACK SN850Xの2TB版 (WDS200T2X0E)
    • mbr2gpt
    • 回復ドライブ用のUSBメモリ(要32GB以上)
    • LBコピーワークス13
    • LBコピーワークス起動メディア用のUSBメモリ

通常起動のWindows上で、起動中のシステムドライブに対して直接mbr2gptを実行するのはよろしくないらしいので、回復ドライブのメニューからコマンドプロンプトを起動してWindows RE上で実行することにしました。
もともと回復ドライブはシステムファイルの破損などでOSが万が一起動しなくなったときに使える手段であり、復旧に必要なシステムファイルを一通りコピーするので作成には結構時間がかかりますが、これを作っておけば内蔵ストレージの回復パーティションは不要だそうです。回復ドライブを使って復旧処理を実行することで、作成時のタイミングにシステムを戻すことができます。ただし、回復ドライブではユーザーデータは復旧対象ではないため、定期的なバックアップではストレージ全体のクローンを作成するようにしたほうがよいです。

外付けHDDは作業途中のバックアップ用です。ディスクのクローンには時間がかかりますが、転ばぬ先の杖としてバックアップは必須です。MBR→GPT変換をかける前や、OSをアップグレードする前にクローニングツールを使ってRAWコピーによるバックアップを実行しています。
今回もクローニングツールとして、Windows PE環境で起動するLBコピーワークスを使用しました。
LBコピーワークスをWindowsにインストールしてから普通に起動し、ディスクコピー処理のタスクを作成すると、OS再起動後にWindows PE上で動作してくれるので、起動メディアのUSBメモリ作成は必須ではないものの、万が一OSが通常起動できなくなったときのために作成しておいたほうがよいです。詳しくは取説のPDFにも記載されています。

WD BLACK SN850XにはAcronis True Imageを利用する権利が付いてくるんですが、以前HDDをクローンしたときに使ったLBコピーワークス11が好印象だったので、今回Windows 10/11対応版であるLBコピーワークス13を購入しました。

sygh.hatenadiary.jp

ダウンロード版は日本の販売代理店のLIFEBOATや、LIFEBOATと提携しているメガソフト、ソースネクストなどから購入することができます。
メガソフトショップのリニューアルオープン時の割引クーポンが残っていたので、普段MIFESでお世話になっているメガソフトへのお布施と思ってメガソフトショップで買いました。

RAWコピーは使われていない領域(ボリュームが割り当てられていない領域)も含めて全体のコピー処理を一律実行するので、ストレージの総容量に比例して時間がかかるようになります。
今回は1TBのSATA HDDを2TBのUSB 3.0 HDDにRAWコピー(バックアップ)するのに2時間程度かかり、2TBのNVMe SSDを2TBのUSB 3.0 HDDにRAWコピー(バックアップ)するのに4-5時間程度かかりました。画面上に表示されるコピー速度はだいたい110-130MB/s程度(おそらくUSB律速)だったので、妥当な時間です。
しかし、1TBのSATA HDDを2TBのNVMe SSDにRAWコピーした際も2時間程度かかっていました。SATA1規格の速度であれば納得いきますが、コピー元のWDの内蔵HDDはSATA3対応のはずなので、微妙に納得がいきません。SATAケーブルは古いものを使っていたものの、転送速度には無関係のはず。

いずれにせよ、SATA HDDをNVMe SSDにクローンした時点でOS (Windows 10) の起動や全体的な動作が爆速になったので、少なくともこの作業だけはさっさとやっておけばよかったですね。

あと4月にマザーボードをASRock B650に交換した後、Windowsが正常に起動するようになったにもかかわらず電源投入後にビープ音が2回鳴っていたんですが、今回CSMを無効化したことでビープ音が1回だけになりました。

Windows 11へのアップグレードには Windows11InstallationAssistant.exe を使いましたが、自分の環境ではダウンロード・インストール・再起動全部含めて完了まで1時間程度で済み、無事24H2になりました。やはりストレージが爆速になったのが効いています。

本当は移行したくなかったWindows 11

Windows 10も機能更新のたびに悩まされたOSでしたが、バージョン22H2が最後の機能更新となり、大幅な仕様変更がなくなったことで、ようやく安定して使える環境になっていました。10月のサポート終了で慣れ親しんだインターフェイスを手放すのは悲しかったものの、これも時代の流れと諦めました。
仕事ではすでにWindows 11を使っているし、実家のPCもWindows 11になっているので、Windows 11がどれだけクソなOSかは事前に分かっていましたが、改めて実感しました。やっぱりWindows 11はクソですね。特にエクスプローラーやタスクバーといったGUIシェルが猛烈に使いづらいことこのうえない。誰もが普段使う機能なのに、Windows 10に比べると超絶的に弱体化あるいは改悪されています。これでも2021年のリリース当初に比べるとかなりマシになってはいますが、結局Windows 10に存在していた機能を機能更新のたびに少しずつ復活させているので、必要な機能を削いで不要な機能をてんこ盛り追加したMSのエンジニアやデザイナーどもが全員何も考えていないアホであったことが逆説的に証明されました。
Windows 11で改悪されたゴミみたいなひどいシェルまわりをWindows 10に近づけるサードパーティ製の各種ツールやModがあることは知っていますが、こういった魔改造ツールはお手軽な反面、悪意のあるコードが紛れ込む可能性が否定できないし*2*3、OSのアップデートで動作しなくなることもあるので、できれば使いたくない。面倒ですがレジストリの編集などで個別に対処していこうと思います。
OSのカーネルWindows 10とほぼ同じなので、よほどのことがない限り10で動作していたアプリはそのまま11でも普通に動作するようですが、GUIに関してはウィンドウの角丸矩形など余計な変更が入っているせいで微妙な非互換が発生しており、手元の環境でも検証が必要そうです。

*1:一応、ストレージのクローニングツールを使えば、GPT変換後のSATA HDDをNVMe SSDにコピーすることもできると思うので、完全に詰むわけではありませんが。

*2:そもそもWindows 11自体もシャレにならないレベルでマルウェア的な動作をする悪意のカタマリと言えますが。

*3:プロプライエタリなクローズソースと比べれば、オープンソース系のツールはコミュニティによって監視されているので、ユーザー数が多ければ危険なコードが紛れ込む可能性は下がるものの、保証されるものではありません。

Xbox 360/Series Xコントローラーの競合とVisual C++ランタイムエラー

ヨドバシカメラエアダスターなどを物色していたところ、Xbox Series X|Sのワイヤレスコントローラー(EP2-29921/EP2-29931など、以下XSXコン)が期間限定セールになっているのを見つけたのでついに買いました。

これまで使っていたXbox 360コントローラー(以下箱丸コン)の左スティックが結構ボロボロになってきていて、そろそろ買い替えようと思っていたのでちょうどよかった。ちなみに360はコントローラーだけでなくゲーム機本体も所持しています。RRoDと修理に出すところまでセットで経験済み。
箱丸コンは流線的なエルゴノミクスデザインで持ちやすく、全体的には使いやすいんですが、ハットスイッチ(十字キー、POVとも)の作りが甘く、正確な入力が困難で、昔のサードパーティ製の安物USBコントローラーと同じ程度の操作感でしかないのが不満でした。歴代の箱コンはPS系とは違って左右スティックが非対称の位置にあり、十字キーはおまけ扱いで、左スティックのほうがメインとなっています。3Dのシューター系ゲームは確かにこちらの配置のほうが適しているんですが、装備切り替えなどで十字キーを使うゲームもあり、正確な入力ができないのは致命的です。Xbox One以降は十字キーも改良されていて、XSXコンは押すと結構大きなクリック音がカチカチ鳴るのが賛否両論あると思いますが、正確な入力を可能とする堅実な作りになっています。

Xbox Oneのコントローラー(以下箱1コン)からの流れで、XSXコンも中央にあるXboxボタン(通称:シイタケボタン)が平べったくなっているのが若干悲しいです。Windows 8以降のフラットデザインに合わせるため、もしくは誤操作しにくくするためなのかもしれませんが、箱丸コンの立体的なデザインのXboxガイドボタンのほうが、オモチャ的な面白みがあってよかったですね。箱丸コンではガイドボタンの周囲に点滅・点灯する緑LED(リングライト)もあって楽しかったんですが、それも廃止されています。

※箱丸コンを知らない人は過去のレビュー記事でも見て想像してください。
www.4gamer.net

いざ接続

ちなみにASRockマザーのBluetoothアダプターを準備していたのは、このXboxワイヤレスコントローラーを使うためでした。

公式サイトのインストラクションに従ってWindows PCとペアリングできました。

コントローラーをペアリングモードにしておき、「Bluetooth またはその他のデバイスを追加する」で「Bluetooth」を選択してHIDデバイスの検出を開始するところがミソです。「その他すべて」の下には「Xbox コントローラーとワイヤレス アダプター、DLNA など」という説明があるんですが、ここで「その他すべて」を選択するとまったく検出されません。これはおそらく「Xbox ワイヤレス アダプター」(専用プロトコルによる独自通信方式)を搭載しているデバイス用の選択肢なので、一般的な汎用Bluetoothアダプターの場合は使えないっぽい。

しかし、接続が成功した直後に、以下のようなランタイムエラーダイアログが表示されてしまいました。

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Runtime Error!

Program: C...



This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.


---------------------------
OK   
---------------------------

これはどうやら、Xbox 360のコントローラーを使うために以前インストールしていた、「Microsoft Xbox 360 Accessories 1.2」が競合しているらしいです。今使っているWindows 10Windows 8.1からアップグレードしたもので、確か2014年頃に "Xbox360_64Jpn.exe" を使ってインストールしていたはず。
Process Explorerでダイアログウィンドウの表示元プロセスを調べると、"C:\Program Files\Microsoft Xbox 360 Accessories\XBoxStat.exe" でした。おそらく新しいXboxコントローラーのデバイスドライバーと何らかの競合が起きて異常動作に陥り、プログラムがプロセスを強制終了するためにMSVCランタイムライブラリのabort()関数を呼ぶことでこのダイアログが表示されています。このダイアログ自体はWindows C/C++プログラマーにとってはお馴染みですね。

XBoxStat.exeはスタートアップに登録されており、OS起動時に毎回自動的に開始されるほか、「Microsoft Xbox 360 Accessories」配下の「Microsoft Xbox 360 Accessories ステータス」というショートカットから手動で起動することもできます。エラーダイアログを回避するために「Microsoft Xbox 360 Accessories 1.2」をアンインストールしてしまう手もありますが、とりあえず自分は「設定」→「アプリ」→「スタートアップ」でOFFにすることによって回避することにしました。

Steamの設定

Steamがインストールされている環境では、Xboxボタンを押すとデフォルトではSteamが起動したり、全画面のBig Pictureモードに遷移したりするようになっています。しかしXboxボタン長押しでコントローラーの電源を切りたいときや、ゲーム中に誤操作したときに邪魔なので、Steamの「設定」→「コントローラ」にて、「ガイドボタンでSteamを手前に表示」をOFF、「コントローラのガイドボタンコードを有効にする」をOFFにしておきます。
Steamによるフックを無効化すると、Xboxボタン押下でWindows標準のGame Barが起動するようになりますが、「設定」→「その他の設定」→「ショートカット」→「コントローラーの Xbox ボタンを使用して Game Bar を開きます」をOFFにするとGame Barが表示されなくなります。Game BarはWinキー+Gでも起動できるので、Xboxボタンによる起動は不要です。
Windows 10ではこれらの設定で解決できましたが、Windows 11ではXboxボタン長押しでタスクビューが表示されてしまうようです(Winキー+Tabと同じ)。Winキー全般を無効化することのできるレジストリ項目はあるものの、Winキー+LやWinキー+Mなどの普段使いたいショートカットもあるので却下。標準のOS設定画面で個別に有効/無効を切り替えることができればいいのに……

なお、Steamのゲーム(『Street Fighter 30th Anniversary Collection』や『Dead or Alive 5 Last Round』)で、XSXコンのボタンが正しく認識されない(アサインがバラバラになる)問題が発生しました。一応Windowsのコントロールパネル上ではすべてのボタンやトリガーが正しく認識されているので、ゲーム側の問題のようです。こういうときはSteam Inputを無効化すると改善されるという情報もありましたが、「XboxコントローラのSteam入力を有効にする」はOFFの状態でした。逆にこの設定をONにすると、ゲーム側でもほとんどのボタンが正常に認識されるようになりました。ただし、DOA5で右スティックが認識されないようです。

どうもBluetoothワイヤレス接続は問題が多いようなので、USB有線接続でやるしかないかも……と思っていましたが、ワイヤレスでも有線でもDOA5では右スティックが認識されない問題が発生します。DOA5では右スティックを使うことはほとんどないのですが、右スティックの押し込みボタンはコマンドトレーニングモードのお手本を見るなどの機能があります。

調査の結果、DOA5のSteam上のコントローラレイアウト設定の問題であることが分かりました。まずSteamクライアントの左ペインのゲームリストからDOA5を右クリック→「管理」→「コントローラレイアウト」で設定画面を開きます(もしくは右ペインのコントローラアイコンからもアクセス可能)。デフォルトでは開発元のTeam NINJAが作成した「Dead or Alive 5 Last Round の公式設定の公式レイアウト」が選択されていますが、これは「右ジョイスティック」の設定が空になってしまっていて、「ジョイスティック」「右スティッククリック」が使えません。テンプレートからValveが作成した標準の「ゲームパッド」を選択し、「レイアウトを適用」で問題が解消されました。なんで公式の設定にバグがあるのか……

※2025-12-12追記:
Windowsの休止モードを使っていると、なぜかXboxボタンやShareボタンが効かなくなることがあります。Winキー+GでGame Barを表示すると復活することもあれば、OSを再起動しない限り復活しないこともありました。他のボタンは正常に動作するので、ドライバーではなくOSかSteamのバグだと思いますが、邪魔でしかないXboxボタンはともかくShareボタンはスクリーンショットの取得に便利なので、突然効かなくなるのは勘弁して欲しい。

www.xbox.com