マイクロソフト自身がElectronを使ってアプリを開発してるのに、他の開発者に何を期待できるんだろう？

Electronの話だけど、自分の小さなツールにはTypeScript+BunとElectrobunを使ってるよ。https://github.com/blackboardsh/electrobun

新しいOutlookとTeamsが混乱してるのは皮肉だね。だって、あれはネイティブアプリじゃなくてウェブアプリだから。ウェブアプリは、ちゃんとしたネイティブの見た目や感触をエミュレートするのが難しくて、フォーカスやキーストロークナビゲーションに関して変な問題がよく起こるんだ。Javaアプリのダメな問題はそのままで、Javaじゃない以外の改善もなく、しかも遅くてメモリを多く使うしね！

Winforms？まだ彼らがベストオプションだなんて笑っちゃう。置き換えようとする努力が無駄すぎる。

大きなレガシーWin32/C++コードベースでの一番の課題は、32ビットから64ビットに完全に移行することだね。複雑なGUIコントロールや構造体に関するノウハウやドキュメントが失われてるか、ほんとにバラバラになってる。それ以外は、そこを乗り越えれば、ほんとに全部うまくいくよ。

どう見えるの？ウィジェットはどんな感じ？

俺にとって、この「何も変える必要がない」っていうのは安定性を示唆してるけど、週ごとに何かが変わるのに慣れてる若い開発者たちがいて、1週間以上古いものは「メンテされてない」って思ってバグだらけだと考えてるんだよね。

俺は、世界で唯一「エレガント」や「よく構造化された」Cocoaコードベースに触れるくらいなら、醜いWin32のジャンクを書く方がいいと思ってる気がする。Win32ではボタンが欲しいときは関数を呼んでハンドルを渡すだけだけど、Appleの世界ではまず7つのインターフェースをサブクラス化して、読みづらいSmalltalk風の構文で書かなきゃいけなくて、ドキュメントにアクセスしないことを祈るしかない。そしてもちろん、彼らは常に何かを変えるから、後方互換性を壊すのがAppleの趣味なんだよね。

APIによって文字列を定義する方法が12通りもあるんだって。

それ、あんまりうまくいかないこともあるよね。運が良かったんじゃない？高DPIを加えると、すぐに厳しくなるし。あと、共通コントロールには変な入力の問題があるよ（Editコントロールでctrl+backspaceを試してみて）。2026年に何かをちゃんと動かすためには、そういう小さな問題を丁寧に修正する必要があるよ。

でも、この記事が言いたいのはそこなんだよ。Cレベルでは完全に機能するシステムがあるけど、その上のレベル（C++レベルでも）では、機能サポートがめちゃくちゃなんだ。

「狂気は個人には稀だが、集団、政党、民族、時代にはルールである」 —F. ニーチェ（皮肉を込めて）

1999年からMFC Win32プログラミングはやってないけど、確かあのプログラムはmain()関数を実行しないんだよね。アプリ用のWin32クラスをインスタンス化する感じだったと思う。もう詳細は全然覚えてないな。

最新の.NETを統合しない理由はいくつかあると思う。まず、.NET 5でセキュリティモデルが変わったこと。次に、Monoや.NET Coreを言語の基盤に組み込んだことで、Windowsネイティブ開発、特にWin32 APIに関するサポートができなくなったこと。 .NET 10を見て.NET 5と比較すると、Win32 APIを再統合しようとしているのがわかるけど、今は新しいMicrosoftの名前空間に入ってる。変更の量が大きすぎて、元の.NETフレームワークの代替品として使うのは無理があるかも。サイドバイサイドのインストールもできたかもしれないけど、.NETフレームワークの急速な開発があって、OSのアップデートに結びつけるのが難しかったんじゃないかな。年に一回か二年に一回のアップデートサイクルから解放して、毎回ダウンロードしてインストールすることで開発を迅速に進めたかったんだと思う。

Windows Updateは昔のやり方で、ひどいよね。アップデートで古いアプリが壊れるか、すべてのバージョンをダウンロードすることになる（現実的じゃない）。新しいアプリをインストールするためにWindows Updateを使いたい人なんている？ただの悪いアイデアだよ。今はDLLをパッケージにして、そのまま動くからね。

.NETには2つのバージョンがある。一つは「レガシー」で、安定していてOSにバンドルされてる。もう一つは「Core」で、サポートは3年だけど100%互換じゃない。最新の.NETランタイムがバンドルされてない理由は、上記の通り、安定版がバンドルされてるからなんだ。

推測だけど、バージョンは完全に後方互換性がないから、最新バージョンだけを出すわけにはいかないんだ。全てを出さないといけない。Windowsに出荷されるバージョンの後に、ほぼ10個の.NETバージョンがリリースされてるし、新しいバージョンは毎年出てる。著者は、.NETにはユーザーにランタイムをインストールさせない配布オプションがあるとも言ってる。ビルドにフルランタイムをパッケージすることもできて、ファイルの束として、自己解凍実行ファイルとして、またはスタンドアロンのAOTコンパイルされたネイティブ実行ファイルとして提供できるんだ。著者はAOTコンパイルされた実行ファイルが9MiBで、それは受け入れられないと言ってた。他のオプションはもっと大きくなるだろうね。個人的には、9MiBは大したことないと思う。特に著者がElectronを選ぶ方がいいって言ってるのに、それは最悪でも大きい（バンドルされたChromium）し、最高でも非効率的（システムWebView）だからね。

スクリーンショットを見る限り、Windows 11スタイルのUIは作れないよね？つまり、https://ntdotdev.wordpress.com/2023/01/01/state-of-the-windo...で探求されている問題に寄与してるってことだよね。

なんでC++ BuilderやDelphiを使わないの？

あんまり言いたくないけど、MFCスタイルのラッパーに対してまともなAPIを考えられるなら、AIが decentな実装を書いてくれるはずだよ。

このルートを進むのが難しいのは、ダークモードのサポートだね。Win32のUSERや共通コントロールはダークモードをサポートしてないし、システム内のハードコーディングされた明るい色や背景のせいで、むしろ敵対的なんだ。システムの色はダーク/ライトの設定に関係なく明るいし、ハイライトはハードコーディングされたライトブルーだし、無効なコントロールはハードコーディングされた色を使ってる。コントロールの色を変更するためのウィンドウメッセージの半分は、テーマが有効になってると無視されちゃう。メニューはオーナードローが必要だから、扱うのが特に難しい。さらに、ダークモードをサポートしているシステムUIが少しだけあって、それが原因でプログラムがダークモードと不一致に見えちゃう。メッセージボックスやファイルダイアログはダークモードに切り替わるけど、Vistaスタイルのカスタマイズを使ってると、システムリンクがダークモードの背景に対して読みづらい青色になっちゃうのが問題だね。

"(2) マイクロソフトが所有しているUIツールキットは使わない方がいい、絶対に痛い目に遭う" これは過去約20年間に彼らが作った技術全てに100%当てはまるけど、WPFとWinformsは非常に安定していて、実際の問題はないよ。過去20年間のほとんどのことは、基本的にWPFの不完全なリミックスだったから、すごく変だよね。もし彼らがWPFを使い続けて、それを拡張していれば、C#に相当するUIツールキットとして、今のWindows開発の金標準になってたし、オープンソースや標準化してれば、一般的なUI開発にもなってたかもしれない。

でも、快適だし、管理された実行環境と比べると実際には面倒くさいよね :-) もちろん、組み込みシステムは別の話だけど…。

でも、Qtをネイティブアプリ開発と考えることはできないよ。だって、どのアプリもQtランタイムが必要だから。ネイティブっていうのは、システムライブラリだけを使うことだよね。

なんで記事がQtに言及してるの？QtはLinuxディストリビューションの一部ではネイティブだけど、Windowsではないよ。

WinJSにちょっと言及したいな。Windows 8のアプリを作って、短期間だけWindows Storeに公開したことがあるんだ。その後、WinJSのUI部分がオープンソース化されて、公式にWindowsアプリを作るための方法じゃなくて、ただのウェブフレームワークになったと思う。これが私のWindows Storeへの挑戦の終わりだったよ。 https://github.com/winjs/winjs

そういう視点で見ると、金曜日のブログ投稿[0]が「コアWindows体験をWinUI3フレームワークに移行する」と発表したのは、そういった体験の質を向上させるための措置として問題だよね。[0] https://blogs.windows.com/windows-insider/2026/03/20/our-com...