Direct Win32 API、奇妙な形のウィンドウ、そしてそれらの大半が消えた理由

 (warped3.substack.com)
7 ポイント 投稿者 GN⁺ 14 일 전 | 1件のコメント | WhatsAppで共有
  • 現代の Windows アプリは Web ベースのフレームワーク依存 によって遅く重くなり、かつての Win32 時代にあった OS レベルの制御権 が失われた
  • Win32 API では メッセージループと HRGN オブジェクト を通じてウィンドウの形を自由に定義でき、非標準のウィンドウデザイン が一般的だった
  • ビットマップと レイヤードウィンドウ技術 を使えば、透明度やアニメーションを備えた 自由な形のウィンドウ を実装できた
  • しかしカスタムウィンドウは、基本機能をすべて手動で実装しなければならない複雑さ と、ユーザーの シンプルさ志向への変化 によって次第に姿を消していった
  • それでも Win32 は今なお ウィンドウ制御と実験の自由 を提供し、創造的なデスクトップソフトウェア制作の可能性 を保っている

現代 Windows アプリの単調さと Win32 が失った自由

  • 最近の Windows デスクトップアプリの多くは、React、Electron、Tauri のようなブラウザラッパー上で動作しており、遅くメモリを過剰消費する 複雑な Web ベース構造 へと変わっている
    • 単純なメモ帳ですら 50MB のメモリを占有する一方、純粋な Win32 C で書かれた同等機能のアプリは 1.8MB にすぎない
    • 最新ハードウェアでも、Windows 11 の起動時にはメモリ使用率が 77% に達する
  • かつて Win32 API を直接使ってプログラミングしていた時代には、OS レベルでの完全な制御権 を持てた
    • 当時は四角いウィンドウに縛られず、非標準の形のウィンドウ を自由に作れた
    • Windows XP 時代には、Windows Media Player をはじめとするさまざまなアプリが独特の外観を備えていた

かつて存在した「奇妙な形」のウィンドウたち

  • かつての Windows アプリは、アイデンティティと個性 を表現するために多様な形で作られていた
    • メディアプレーヤーはハードウェアのように見え、デスクトップマスコットが画面を歩き回り、ユーティリティパネルは 計器盤、おもちゃ、異星のコンソール のようにデザインされていた
    • ウィンドウの形は四角形である必要がなく、UI の目的は使いやすさよりも個性 に近かった
  • 今日こうした形が消えた理由は、プログラマーがもはやウィンドウそのものを制御していないから だ
    • 現代の UI フレームワークの多くは OS を隠してしまい、開発者は制限された四角い領域の中でしか作業できない

Win32 のメッセージベース構造とウィンドウ制御

  • Win32 プログラミングの中核は イベントメッセージループ にある
    • GetMessage、TranslateMessage、DispatchMessage から成るループが、すべての動作の基盤になる
    • “WM_CREATE”、“WM_PAINT”、“WM_SIZE”、“WM_DESTROY” などのメッセージを処理して、ウィンドウの挙動を定義する
  • HRGN（リージョンオブジェクト） を使えば、ウィンドウの形を自由に変更できる
    • SetWindowRgn でウィンドウに領域を指定すると、その領域だけが実際のウィンドウとして認識される
    • サンプルコードでは CreateEllipticRgn で楕円形のウィンドウを作り、タイトルバーがない状態でドラッグ機能を自前で実装 している
    • “WM_LBUTTONDOWN” 時に “WM_NCLBUTTONDOWN” を “HTCAPTION” として送ることで、ウィンドウ移動を擬似的に実現 する
  • このように 形を作ること自体は簡単 だが、標準フレームが提供していた機能を自分で実装しなければならない点が本質的な課題となる

ビットマップベースのウィンドウとレイヤードウィンドウ

  • “drivenbyimage/main.c” のサンプルでは、ビットマップデータでウィンドウの形を定義 している
    • “shape.bmp” を読み込み、透明色（マゼンタ） を除いたピクセルをウィンドウ領域として設定する
    • ビットマップは同時に 画面に描画される画像であり、ウィンドウの実際の形でもある
    • かつてのスキン型アプリはこの方法で、子犬、宇宙船、ラジオ、キャラクターの顔 など多様な形を実現していた
  • ただしビットマップベースの領域は、輪郭が硬く、半透明表現ができない
    • 滑らかな縁やアニメーションのためには、レイヤードウィンドウ（WS_EX_LAYERED） が必要になる
  • “Animated/” のサンプルでは、透明なアルファチャンネルを持つ 32 ビット画像 を UpdateLayeredWindow でアップロードする
    • GDI+ でメモリ上のビットマップにスプライトシートを描画してフレームを切り替え、それをデスクトップ上に表示する
    • ウィンドウの形は固定されているのではなく、現在のピクセル状態そのものがウィンドウの形 になる
    • この方式は 滑らかな透明度、フレームごとの形状変化、自然なアニメーション をサポートする

カスタムウィンドウの難しさと文化的変化

  • Win32 API でカスタムウィンドウを作ると、あらゆる細かな挙動を自分で処理しなければならない
    • ドラッグ、リサイズ、閉じる操作、キーボード入力、DPI 対応など、標準ウィンドウが自動処理していた機能を手動で実装 する必要がある
    • プロトタイプを作るのは簡単でも、完成度の高い製品へ磨き上げるには 大きなコストと労力 がかかる
  • ユーザーはこうした視覚的実験よりも 安定性とシンプルさ を好むようになった
    • 非標準ウィンドウはしばしば アドウェア、ツールバー、不要なユーティリティ と結び付けられ、否定的なイメージが生まれた
    • その結果、「奇妙な形のウィンドウ」は 真面目なソフトウェアよりも遊び心のある要素 と見なされるようになった

Win32 に今なお残る可能性と意味

  • それでも Win32 は今なお 直接制御と実験の自由 を提供している
    • メッセージ、ハンドル、描画 API だけでも OS レベルのウィンドウ制御 が可能だ
    • 多くの場合、四角いウィンドウは合理的だが、その形は選択にすぎず強制ではない ことを思い出させてくれる
  • サンプルコードは GitHub リポジトリ WierdApps で公開されている
    • 楕円形ウィンドウ、ビットマップベースのウィンドウ、アニメーションするマスコットの 3 つのサンプルを含む
    • Win32 が今なお 創造的で実験的なデスクトップソフトウェア制作 を可能にしていることを示している

関連記事

1件のコメント

 
GN⁺ 14 일 전
Hacker Newsのコメント

  • 奇妙な形のウィンドウは戻ってきてほしくない
    作れるからといって、作るべきとは限らない
    最近の React, Electron, Tauri のようなブラウザラッパーで作られたアプリがどれも似た見た目なのは、OS の GUI フレームワークを使っていないからだ
    アプリがそれぞれ独自の 非標準ウィジェット や色、形を使うと、アクセシビリティと使いやすさが損なわれる
    皮肉なことに、最近「アイデンティティ」を強調するアプリの大半は、ハードウェアメーカーが押し込んでくる ドライバー用コントロールパネル のようなもので、しかも最悪のブロートウェアだ

    • Electron はむしろ逆の問題を生む。すべてのアプリがそれぞれ違って見えて、プラットフォームガイドライン に従わない
    • アクセシビリティは法的要件でもある重要な要素だ。最新の クロスプラットフォーム GUI フレームワーク は、視覚障害者向けのスクリーンリーダーや HiDPI 対応をうまく処理している
    • それでも私は、そういう 変わったウィンドウ形状 は格好いいと思う。誰かがまた試すなら歓迎したい
    • Vista 時代の WPF と XAML で作られた非標準 UI をたくさん見たが、ウィンドウのサイズ変更やモニター移動時のスケーリングがひどく、結局は不便さだけが残った
    • 私の考えは正反対だ。昔のようにコンピューターを 楽しくて格好いいもの にしたい。今はどれも書類棚みたいだ。人生の楽しい部分はもともと必須ではなく、選択的なものだ

  • 私は Win32 は好きだが、昔の奇妙なスキン文化は、今の「ブランディング = アイデンティティ」という考え方の前兆だったと思う
    それが結局、Electron と中途半端なウィジェットライブラリ の乱立につながった
    Blender や Ardour のような特殊なアプリでない限り、個性的な GUI は優先事項ではない

    • Electron アプリはどれも同じように見える。対して Winamp のような Win32 スキン には、少なくとも個性があった
      今の OS は個人向けではなく企業向けだ。Win3.1〜XP 時代 こそ本当のパーソナルコンピューティングの時代だった
    • 一般的な業務アプリならネイティブコントロールを使うのが正しいが、iPad やスマートデバイス のように全画面をカスタム UI にするケースでは、格好よく、しかもうまく機能する

  • 最近の React ベースのアプリ は、OS とも、互いの間でも一貫性がない
    6か月ごとに UI が変わるのに、UX は改善されない。アクセシビリティ（a11y）は完全に忘れ去られている

  • 昔は少人数でソフトウェアを作り、長期間にわたって安定的に保守していた
    今は高速な反復と大規模チーム中心に変わり、フラットデザイン はそうした環境に適応した結果だ
    スキューモーフィックデザイン はアセットを作り直し続ける必要があり、コストが高い
    結局、速度と規模 が優先される時代になった。まるで手彫りの家具の代わりに 平板な組み立て家具 が主流になったようなものだ

    • 実際、Win32 API でもすべてを直接実装する必要はない。基本的なメッセージ処理を 委譲（delegate） すればいい
    • スキューモーフィックデザインは現実の模倣が行き過ぎていて、視覚的に複雑で雑然 としていた。方向性は良かったが、実装が難しい
    • 結局のところ理由は コスト削減 だ。より良い使い勝手を捨てて、自動車のボタンを 大型タッチスクリーン に置き換えたのと同じだ

  • HiDPI 時代になって、昔のようにピクセル単位で UI を描くのは難しくなった
    昔の Win95〜XP 時代は フロントバッファに直接描画して 高速でメモリ使用量も少なかったが、今は各ウィンドウごとにバックアップバッファを維持するため RAM をより多く使う

  • 「The point was usually not usability. It was identity.」という文を見て、LLM が書いた文章 のように感じた

    • 私も同じ印象を受けた。それでも筆者が何か言いたかったことは伝わってきた
    • すべての文が LLM が生成したもののように 見えた

  • 昔 Windows アプリを開発していたが、Win32 インターフェース は 90% 程度しか制御できなかった
    カラーテーマを変えようとして、MessageBox を自分で再実装 しなければならなかった記憶がある

    • 昔は Win32 Hook で MessageBox を変更できた。HCBT_CREATEWND で HWND を取得して サブクラス化 すればよかった
    • さらに深く入ると、User32.dll ではなく Win32U.dll をフックしなければならない場合もある
    • それを自分で作り直すのはつらい。Qt なら少しはましなのか気になる

  • 純粋な Win32 C で作られた Notepad は 1.8MB しか使わないのに、今どきのメモ帳は 50MB も使う

    • 最小限の “Hello World” プログラムですら 500KB は必要だ。システムライブラリがデフォルトでメモリを消費する
    • 最新の Windows 11 Notepad は、タブ、スタイル付きテキスト、AI 機能まで含まれていて、標準で 32MB を使う
      しかも GNU Emacs のほうがより少ないメモリで済む
      一方、テキストモードの EDIT.EXE は 520KB しか使わず、はるかに効率的だ

  • 以前、Mac 向けに Disco という CD 書き込みアプリがあったが、ディスクを書き込んでいる間、ウィンドウの上に 煙が立ち上るアニメーション が表示されていた
    Steve Jobs がステージで直接見せながら気に入っていた

  • 記事で デスクトップマスコット の話も出てきてうれしかった
    最近、Godot で作られたデスクトップペットの動画 を見たが、クロスプラットフォームで動作する
    少し手間はかかるが、Win32 レベルの複雑さではない。デスクトップペット愛好家 には良い選択肢だ