野良犬日記 2.1

_ バンポ電話対応

スマホ買いかえ等の関係で自宅のネットも固定電話も会社を変えてみた。

ネットのほうはフレッツからドコモ光にしたけど、いつ変わったか分からない感じ。ホームゲートウェイを接続しておけばいい。(朝9時までにHGWを用意しておくよう言われていたが、その前から新しいISPにはPPPOEで接続できていたようだ)

固定電話のほうは、ひかり電話の番号へ午前中に電話してくれと言われていたので、ネットのほうの工事がおそらく終わったのだろうと思える時間 (朝10時すぎ) になってから電話をかけた。

それまでのドコモ関係の電話はまさにプロの電話受付といった感じで丁寧で分かりやすかったので今回もそうだろうと思っていたところ、度肝を抜かれた。

「あー、どしたの？」

「番号は？」

「これね、バンポだから開通したあとまた電話してね」

いかにも現場のおじさんといった感じの人が、ぶっきらぼうに業界用語を使いまくるのだ。こちらは

「バンポって何ですか」

「番号が下りてくるってどういう意味ですか」

と、ぜんぶ聞き返さなくてはいけない。

けっきょく、一回目の電話でホームゲートウェイに「ひかり電話」を開通してもらって、(HGW の「ひかり電話」LED が光ってから) その後もう一度電話して電話番号を移してもらうということのようだった。

今はスマホもあるから何かを間違えて電話が不通になってしまっても別経路で対応できるわけだけど、要らない書類をたくさん送ってくる割に最後の大切な段階について説明が雑だったのはちょっとこわかった。

_ [ahk]Windows の不思議セキュリティ、あるいは頑固な UWP のなだめ方

 TL;DR
 本当に always-on-top にしたければ
 その実行ファイルは
 UIAccess の諸条件をクリアしなければいけない

AutoHotkey で Always-on-top に設定した Gui を作って表示したところ、 一部のウィンドウの上には表示されず、隠れてしまうという現象が起こった。 (その「一部」が UWP アプリであることは後から分かった。)

再現条件が複雑で、

• AHK スクリプトとして実行するなら再現しない (問題の UWP アプリの上に表示できる)
• Ahk2Exe でコンパイルすると再現する (UWP の上に表示できない)
• いや、スクリプトでも再現するマシンと再現しないマシンがある

と、かなり迷走した。

AHK に関係のない他のウィンドウで試してみると、

• タスクマネージャーは再現しない (件の UWP アプリ上に表示できる)
• LibreOffice とか Firefox とかでは再現する (UWP の上に表示できない)

ということが分かった。

そんなことないと思う人は試してみてほしい。 複数モニタがあれば、一つに Windows 標準の「映画 & テレビ」で何かの動画をフルスクリーン再生して (一時停止しておいてもいい)、そこに別のモニタからのウィンドウを移動していくとどうなるか。

タスクマネージャーを移動していくと何事もなく重なるのに、 普通のウィンドウを重ねようとすると、途中までは下に潜りこむような感じで隠れていて、ある程度まで来ると「映画 & テレビ」の方が消えてしまうのだ。

タスクマネージャーはすごく変なアプリだから特別なのかもしれないと思ったが、AutoHotkey 付属の Window Spy もタスクマネージャーと同じ結果になった。というか AutoHotkey が C:\Program Files にインストールされているマシンでは AHK スクリプトから UWP の上に表示できるみたいだ。同じ AHK スクリプトを実行して UWP に隠れてしまう方のマシンには AutoHotkey をインストールしておらず、zip を展開した状態で使っていた。

ここに来てやっと分かった。Ahk2Exe してあるかどうかというより、UIAccess 権限があるかどうかが問題だったのだ。

それまで権限の問題と思えなかった理由は、「管理者として実行」をしても現象が変わらなかったからだ。AutoHotkey のドキュメントでも、UAC の問題は UIAccess と管理者権限のどちらでも解消できると書いてある。https://www.autohotkey.com/docs/v2/FAQ.htm#uac これは少し誤解を招く文かもしれない。

というわけで結論として、UWP の中でもさらに特殊な条件を含めた really-always-on-top を実現するためには、UIAccess が必要である。WinSetAlwaysOnTop の remarks にも書いておいてほしい気がする。

UIAccess のための条件

• AHK スクリプトのまま使う場合は、AutoHotkey を C:\Program Files にインストールすればいい
• Ahk2Exe する場合は、以下のすべてが必要
  • ;@Ahk2Exe-UpdateManifest 0,,,1して
  • Set-AuthenticodeSignatureして
  • UAC プロンプトを必要とする場所 (C:\Program Files等)に置く

もっと良い方法もあるのか？

最後のリンク https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-securityoverview#uiaccess-requirements-for-assistive-technology-applications には

 UIAccess should not be used:
   By applications that are not assistive technologies.
   By assistive technology applications that display information or UI that is not relevant to the accessibility scenario they target.
   By applications that just want to appear above other applications in the new Windows UI.

と書いてある。まさに今回のことを言っているようだ。こんな場合は UIAccess を使うべきではない！ とだけ書かれても、どうすればいいのか分からない。

_ windows の stdin て面倒

   fopen_s(&f, "testfile.bin", "wb");
   for (unsigned char i = 0; i < 256; ++i) {
       fputc(i, f);
   }
   fclose(f);

で出力したファイルを fread すると普通に 7F の次は 80 になるのに、pwsh から

 Get-Content testfile.bin | program.exe

みたいにパイプして stdin を fread すると 7F の次が EF BF BD と 3 バイトに膨れる。

あ、その前に 1A のところで EOF と思って止まってしまうので

 _setmode(_fileno(stdin), _O_BINARY);

とかいうものも必要。(stdin の freopen はできない？)

で、80 が EF BF BD になる問題。

最初は 80 が EF になるのかと思って、キャストすれば直る？ とか思ったけど、よく見ると EF じゃなくて EF BF BD になっているので、signedness とかより、エンコーディング関係の問題に見える。

結論としては、pwsh の Get-Content が勝手にテキストとして処理しているのが悪かったので、

 Get-Content -AsByteStream testfile.bin | program.exe

なら問題なかった。

他のプログラムからのバイナリデータはどうなるのかは未確認。

windows の微妙に portable にならない部分が気持ち悪いのは前からだけど、pwsh も罠だらけだ。(標準 powershell や古い pwsh と pwsh7.4 でそれぞれ違ったりする)

_ [ahk] Ahk2Exe の github action

毎度 yaml 書くの面倒なので https://github.com/tamo/action-Ahk2Exe にまとめた

_ [js]はてブのコメントもマウスホバーで見たい

YouTube コメントをホバーで一覧するやつ

https://github.com/tamo/yt-comments-popup/compare/v1.2.4...hatena

適当に b.hatena.ne.jp で動くようにした