Windows 11 のエクスプローラーにタブ機能がついたというので、 QTTabBar を無理矢理消したら、 フォルダをひらくたびにエクスプローラーのウィンドウが増殖する問題に悩まされた。
レジストリをいじれば一発で直る。 HKEY_CLASSES_ROOT\Folder\shell にある「（既定）」というやつに値が入っていたら、それを消せばいい。
HKEY_CLASSES_ROOT というのはファイルタイプの開き方を保存しているらしい。 Windows のことはよく知らないので雰囲気で書いているが、新しいウィンドウが開いてしまうのはフォルダを開いたときに QTTabBar のルーチンが呼び出されるように設定されていることが原因のようだ。 QTTabBar はアンインストールされているので実際にはこの呼び出しは失敗するが、 そのフォールバックでエクスプローラーで開く（explorer フォルダ というコマンドを実行する）という動作になっているので、 毎回新しいウィンドウが開かれてしまっていたということのような気がする。
Windows のイメージは Microsoft のサイトからダウンロードできるが、 クソデカファイルが含まれているので、そのまま焼いても (USB の作成は成功したように見えるが) 壊れた起動 USB ができている。
FAT32 は 1 ファイルのサイズには 4 GiB の制限があるが、ISO ファイルには 5 GiB 超の ファイルが入っているのでそのまま焼くことができない。 このクソデカファイルを分割することで、この制限を突破することができるので、 その方法で起動用の USB を作成する。
1. USB を FAT32 でフォーマットする 普通。コマンドでやるなら下みたいな感じかな。
# parted /dev/sdb (parted) mklabel msdos (parted) mkpart primary fat32 0% 100% (parted) q # mkfs.fat -F32 /dev/sdb1 sources/install.wim 以外をコピーする ダウンロードしてきたイメージをマウントし、中のファイルをコピーする。 cp でやるなり rsync 使うなりお好みで。
ウェブのいろんなところに書いてあるけどレジストリをいじる。
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Keyboard Layout] "Scancode Map"=hex:00,00,00,00,00,00,00,00,02,00,00,00,1d,00,3a,00,00,00,00,00 CapsLock を読んだら Ctrl として解釈するみたいなマップになっている。 空で書けって言われても無理。
バイトオーダー依存だとか。いくらなんでもイケてなさすぎる。
ということを最近知った。ハイバネートというのは現在のメモリの状態をハードドライブに永続化して CPU やメモリへの電源供給を止めることだ。
起動時のパフォーマンス改善のためらしく，試しにハイバネートさせない設定にしてみたら たしかに起動が少し遅くなる。
シャットダウンしたときにシャットダウンするようにする方法を簡単に説明すると，
コントロールパネルを開く（検索などの機能を使えば簡単に開ける） 「システムとセキュリティ」を開く 「電源オプション」を開く 「電源ボタンの動作の選択」（左側のメニュー）を開く 「現在使用可能ではない設定を変更します」のリンクをクリックする シャットダウン設定の中から「高速スタートアップを有効にする」のチェックを外し，変更を保存する ハイバネートの設定になっている場合，デュアルブートなどで別の OS の環境から ストレージを触ると内容が破壊されることがあるらしい。おそろしあ。
NMake は並列でビルドできないという問題があるので，JOM という NMake のクローンを使う。 これは Qt の開発元が作っているらしい。
ビルドするのは面倒なので適当に公式からバイナリ配布を拾ってくる（ソースコードかと思ってダウンロードしてみたらバイナリだった）。 で，面倒なので PATH を通す。こういう具合でどんどん PATH を通していくと膨大な PATH になってしまう訳ですね。
で，CMake で JOM 用の Makefile を生成する。
$ cmake -G"NMake Makefiles JOM" .. これで
$ jom /J 8 とかすると 8 並列でビルドされる。おしまい。
UNIX で Makefile 生成してビルドしていたような CMake のプロジェクトを Windows に移植する。
ここでは Visual Studio について言及するとき Visual Studio 2019 を前提とする （というか試せる環境がそれしかない）が多分そこにはそんなに依存していないはず。
とりあえず言えることは，CMake で Visual Studio のプロジェクトを生成する方法は Make を使ったプロジェクトとビルドシステムの設計というか思想が違いすぎてその差異を CMakeLists.txt で吸収するのは無理だと思う（たぶん単純なプロジェクトだと大丈夫だけど凝ったことをしようとすると すぐ詰む）。書くの面倒臭いので飛ばすけど Visual Studio は CMake では Multi-config という扱いになって Makefile とはちょっと違う環境になるので。 というわけで，NMake の Makefile を生成するのが簡単な方法だと思う。 この方法だと最小限のプラットフォーム固有の（cmake の）コードでビルドが通るようにできる。
Visual Studio 入れて試してみたら簡単だった（今まで MSYS2 入れて UNIX Makefile を生成してビルドしていた）． 基本的には root の CMakeLists.txt があるディレクトリを Visual Studio の「フォルダを開く」的な メニュー（プロジェクトを開くに非ず）から開けばいい感じに cmake を実行するところまでやってくれる．
ただちょっと困っているのが pkg-config がないことだ． もっとも Windows にはシステムに1つライブラリを入れて多数のアプリから使うという 習慣がなさそうに思われるので，システムに入っているという状況が普通ないというのは理解できるのだが． しかし依存関係しているライブラリを全部 CMake でダウンロードしてビルドして，というのは流石に 面倒臭すぎる．どうにかならないものだろうか．
MSYS2 でビルドする場合だと，（あの空間は *nix 的な設計がされているので）pkg-config で依存するライブラリのインクルードパスやライブラリの設定ができた． そして，ldd とかで依存しているライブラリを調べてそれらと一緒に他の環境に持っていけば 問題なく動作させることができた（というのも Windows はライブラリを探すときに最初にその executable があるパスを探すので）．