Windows C/C++ DIB 検証報告プロジェクト GraphicBuildTrial ０２／０２ 2026/06/08
※ ここでは Windows 10 / 11 のＰＣを前提としていること、無料公開されている Microsoft Visual Studio Community 2026 がインストールされていて当アップロードファイルのプログラムソースファイルを確認できる前提、統合前 32 Bit 時代の Windows 標準 API 中心（ 原点回帰中心 ）を前提に、プログラム設計の上達（ 自分たちにとっての上同士視点といえる、何にでもいえる年期計画的な目的構築・組織構想に結びつく異環境間領域敷居管理・式目序列規律更新観 ）においてやってしまいがち・陥りがちなあるある話の教訓を議題としている。
※ 当ブログの解釈・意図の構築の仕方は、それは当ブログ筆者がたまたま統合前 32 Bit 時代から見渡してきた Microsoft の Windows 標準 API 史的、CRT 史的、UNICODE 対応史的な、統合期 Windows XP 以後 64 Bit 化以降も進められてきたここ３０年のＯＳ内部仕様をざっとの Microsoft のＣ原点回帰的な概念整理をＩＳＯ９０００系善用重視で見渡した上であること、またそもそもの当ブログ記事の目的・動機・前提等の式目敷居観についても、そこに間違いのないようこれまでひと通り説明してきている。
※ よそのこと道義領域外のことがどうであれの、まず自分たちの前提（ 上同士視点の上方修正といえる社訓的な式目敷居交流規律・近代選任評議会的規律 ）がそもそもどうなっているのかを最初から最後までケンカ腰に徹底的に面倒がり合うことしか能がない、目先の利害次第に何もかもをうやむやにし合う下の作り合いに全意識を全力で向け合うことしか能がない教育機関絶対どもおよびオブジェクト指向の規律絶対どものような上同士失格の怠慢の顔色のたらい回し合い・厳しさの向け合い（ ＝ ただの性善説放任主義・偽善憎悪・老害浪費の乱立拡散 ）は、ここでは次世代交流規律（ まずは上同士視点の上方修正の手本といえる原本からの、きざみ下方修正的・年期計画的な段階・階層・境界・領域敷居管理観の手本 ＝ 荀子・韓非子・孫子の兵法の組織論の手本 ）荒らしの法賊行為・老害愚行と見なし、上から順番の厳しさ上乗せ倍増論で踏みにじって当然が前提になっている。
本題に入り、今回は、前ページ０１／０２の方でアップロードした GraphicBuildTrial プロジェクトのソースプログラム側についての紹介をする。
今回議題 GraphicBuildTrial プロジェクトは、Windows 標準 API の自由的グラフィック表示仕様 DIB（ Device Independent Bitmap ）の紹介だが、今回も今まで通り統合前 32 Bit 時代（ ３０年前の Windows 95 / Windows NT 4.0 時代以来の仕様 ）のみの使用による原点回帰的な紹介となる。
DIB の紹介においては、同時に FPS（ Frame Per Second ）とは何なのかの理解も必要であることに、注意になる。
そのため FPS についても大まかにでも理解できていないと、ここでの意味がなお難解になってしまうため、その場合はまず前ページ０１／０２でその概要を確認しておかなければならないことを念押ししておく。
まず、Ｃの前方宣言のプロジェクト共用手続き（ 関数・プロシージャ ）と、共用構造体（ グローバル struct / class 変数 ）の設置からの説明に入るが、今回 GraphicBuildTrial では、前章 AssistKeep までのダイアログ式部品（ Windows でおなじみの入力項目やボタンやリストボックスやツリー表示などで構成される画面形態 ）はいったん除外している。
今回 GraphicBuild はダイアログ式の画面構成は用いないため、それまでその中心だった０５章 AssistKeep とは別系譜的となる、０３章 WindowOrigin （ 何もないウインドウをただ表示するだけの状態 ）からの今一度の新規的な作りになっていることに注意になる。
＜ 赤 前方宣言 １ ＞
０３章 WindowOrigin で説明した、メインウインドウ表示の Microsoft 見本（ デスクトップアプリケーションからの新規プロジェクト ）を元手にしている部分。
０３章で説明している通り、Microsoft 独自仕様のアイコン情報は除く内部リソース部分は削っての、非ＭＦＣ状態のものを元手にしている。
＜ 赤 前方宣言 ２ と ３ ＞
今回、FPS の仕組みを意識しながらの DIB 仕様による BMP 表示処理ということで、ViewBmp という構造体と、ViewTask という構造体のデータ計画を元に、
ViewBmp BMP データの読み込みの初期設定的な管理。
ViewTask 読み込まれた BMP を表示していく上での種別分類的な役目・挙動と FPS 時間の管理。
の意味分けをして、struct 内手続き化（ class 内。クラス関数設計 ）はいったん避ける形で、そうしたい場合にしてもそうしない場合にしても工夫しなければならない概念名に注意しながら、ViewBmp から始まる手続き名と、ViewTask から始める手続き名とで並べている。
＜ ViewBmp 構造体用の手続き ＞
①Ａ ViewBmpInit Bmp １件単位の読み込みおよび、役目等の初期設定。
②Ｂ ViewBmpEnd ViewBmp 情報全体のメモリ解放等の終了処理。
＜ ViewTask 構造体用の手続き ＞
①Ａ ViewTaskInit 表示の各役目概念の初期化
②Ａ ViewTaskAct 動作変更や開始的な指示
③Ａ ViewTaskPos DIB 側と BMP 側との間の表示座標計算
④Ａ ViewTaskFPS 現在 FPS 算出
⑤Ａ ViewTaskNext FPS 進行による各役目概念の計画的・数値管理的な動作遷移
⑥Ｂ ViewTaskBuild ViewTask 情報全体（ 各役目全体 ）に対する１フレームごとの BMP 表示
今回 GraphicBuildTrial のプロジェクト内共用手続きは、Microsoft 見本由来の基礎３個（ wWinMain、MyRegisterClass、WinProc ）を除くと、ViewBmp 管理側２個、ViewTask 管理側６個の合計８個と、小規模になる。
しかし小規模でも、FPS の事情も併（ あわ ）せての DIB プログラム設計の構造は、慣れていないとだいぶややこしい。
なお、今回のこの手続き名（ 関数・プロシージャ名 ）は概念名整理はざっとはしているが、ここからの概念名の改善余地などいくらでもあるが、だいぶ時間がかかりそうだったこともあって今回はいったんこの形で紹介することにしたに過ぎない。
共用変数にしても共用手続きにしても、概念名統制はこれまで指摘してきたデータ計画優先による上達の重要事項として、そこは常に怠ってはならない所になる。
FPS と DIB を両立させるようなややこしい構造こそ、手続き、変数、定数ごとのまずは概念名からを面倒がらずに何度も見直し（ 意義・象形の概念整理 ）ていくまずは自分たちのそもそものその基本姿勢（ 前回分・今回分・次回分以降の見渡し ）が、上達の鍵として非常に重要になってくる、つまり
自分たちの概念名（ 式目名 ）の用い方（ ＝ 自分たちの論述整理性・議事録処理性の敷居交流規律にそのまま直結 ＝ 変数・定数・手続きの概念間計画、想定値計画のデータ設計優先の向き合い方にそのまま直結 ）の内、表装をただ丸覚え的に片手間感覚で飾り並べたてているまま、ズレ、ブレ、不一致がいつまでも著しいまま（ いい所できている気・解った気に気取りたがる ）、意味不足（ ＝ 式目不足 ＝ 概念間の境界管理不足・段階管理不足・階層管理不足・セグメントマネジメント不足 ＝ 再細分化不足と再集約化不足 ）のままの自分たちの改善余地（ 自分たちの式目規律の更新不足 ）を自分たちで直そうとしない、すなわち自分たちの次の段階のための自分たちの上同士視点の上方修正の手本・原本の作り合いを目先の利害次第に上同士失格の怠慢の顔色（ ただの性善説放任主義・ただの偽善憎悪任せ・ただの老害浪費任せ ）を向け合い徹底的に面倒がり合いうやむやに壊し合う自分たちのその愚かさだらしなさも自分たちで直せたことがない（ 自分たちの前回分・今回分・次回分以降の履歴管理も自分たちでできない ）、国際広域の式目敷居競争でつまづいて息切れを起こすならまだしも分野狭義内・小異環境間の式目敷居競争の段階でいとも簡単につまづいて精神的支柱を崩壊させ合うことしか能がない教育機関絶対どもやオブジェクトの規律絶対どものような気の小さい知能障害の集まりの姿
の典型に陥らないようにするために、よそのこと道義領域外のことに無神経・無関心・無計画な厳しさ（ 低次元化させ合う上同士失格の怠慢の顔色 ）を向けようとする前の、まずは自分たちの概念間整理からの地道な取り組みこそが、
★ 自分たちがしなければならない自分たちの次の段階に向けての、まずは普段からの各概念間の扱い方（ 式目敷居規律 ）に対する再細分化どころ（ 別概念が目立ってきた詰め込まれ箇所の分離化計画 ）と再集約化どころ（ まとめ直せそうな同概念が目立ってきた分散箇所のまとめ直し計画 ）の自分たちの改善余地を自分たちで見つけやすくしていく鍵
★ 自分たちの入力敷居観（ 何が起きているのかの主に当事者軸・再細分化の概念間認識力。主にデータ設計側 ）と出力敷居観（ それにどう対応していくのかの主に主体軸・再集約化の概念間認識力。主にアルゴリズム設計側 ）の幅を広げるための、列挙しようと思えばいくらでも列挙できるはずの自分たちの改善余地に対する段階計画を自分たちで見つけやすくする鍵
★ すなわちプログラム設計の上達（ 今後の想定規模の予定計画 ）において重要になってくる自分たちの改善余地に対する履歴管理（ 前回分・今回分・次回分以降 の見渡し ）による段階／階層計画（ 自分たちの旧廃策の互換／非互換の統廃合管理 ＝ Microsoft も Windows 標準 API 側では 64 Bit 化以降も進められてきた手本的な概念整備どころ ）の見通しを自分たちで立てやすくしていく鍵
になる。
荀子・韓非子・孫子の兵法の組織論の指摘通りの、自分たちの目的構築／組織構想の原本、すなわち自分たちの上同士視点（ ＩＳＯ９０００系善用 ）といえる自分たちの年期計画的な式目規律の更新観（ 自分たちの上方修正の段階管理・階層管理・領域敷居管理 ）の手本の作り合いを互いにうやむやにさせ合わないよう、まずは敷居交流規律の問い合いが最優先になっていて当然でなければならないのが本来の選任評議観・国際人道観（ まずは自分たちの上同士視点の上方修正を自分たちで明確化させ合っていく式目整備・等族義務の果たし合い ）の基本中の基本。
× コイツは社会の正しさ厳しさの痛い目に遭っていないに違いないから「そんなこともワカランノカ！」「何を逆らっているんだ！」を思い知らせてやらなけばならない！
〇 何もかもが痛い目任せ絶対になっているような、手遅れ寸前と手遅れの狭間が何もかもの初動絶対（ 上同士失格の怠慢の顔色任せの目先の利害体質 ）の自分たちの愚かさだらしなさを自分たちで敷居交流規律（ 論述整理性・議事録処理性がもたれた履歴管理の見渡し方の手本 ）を以って年期更新（ 次の段階に向けた上同士視点の上方修正の原本といえる選任評議的な序列敷居整備 ）してこれなかった時点で遅い！
＜ 赤 プロジェクト共用変数および定数宣言 ４・５ と ６・７ ＞
４・５ は BMP の読み込みと初期設定に関する ViewBmp 構造体と、それに関する VIEWBMP_ から始まる役目管理（ CATE ）の定数。
６・７ は BMP を表示するための種別管理および FPS 動作計算に関する ViewTask 構造体と、それに関する VIEWTASK_ から始まる状態管理（ STATE ）の定数。
＜ 赤 プロジェクト共用変数および定数宣言 ８ と ９ ＞
この部分は ３章 WindowOrigin ４章 WindowBuild ５章 AssistKeep の時と同じ、メインウインドウを生成する際のウインドウキャプション名と識別登録名のための文字列と、メインウインドウハンドル（ HWND ）を保持するための変数。
HINSTANCE 型変数、 HWND 型変数、HDC 型変数、構造体番地変数、文字列番地変数、プロシージャ番地変数はいずれも機械語内部の性質としては void * と同じ番地変数（ 64 Bit コンパイルなら 8 バイト変数領域 ）に過ぎないがしかし、Microsoft が用意してくれている各概念ごとの番地変数にいったん沿っておくことが、概念間整理において重要になる。
＜ 赤 プロジェクト共用変数および定数宣言 １０ ＞
今回議題である Windows 標準の DIB 用の変数群。（ HFONT の方は、今回では DIB とは関連しない使い方をしているが、次章予定 GraphicBuild では HFONT も DIB と関連した使い方をする ）
HBITMAP 型や HFONT 型は、使い慣れていない内のパッと見だと構造体なのか何なのかが解りにくいかも知れないが、H から始まるこれらは Microsoft 側が各概念ごとで用意しているハンドル変数（ 番地変数だが、Windows 標準 API 間の機能種別ごとのコンテキスト間アクセスキー発行の意味のものが多い ）になる。
※ プログラミング関連で、使用言語によってはよく使われるコンテキストという言葉の意味は、その内部情報に対してのことや、その操作用発行キーなどの意味で用いられることが多い。Windows 標準 API 側では、パソコン周辺機器間のやりとり、ディスプレイの詳細に対してだったりプリンタの詳細に対してだったりのコンテキストキー発行の仕様をデバイスコンテキストという概念総称でいったん統制しようとしているが、内部機械語的な性質（ 高級言語的でない性質 ）がどうも強いと見たせいか、拡張 API 側（ Microsoft Direct X ）ではその概念総称は使われなくなっている。
BYTE * g_pViewDIB 変数が、1 / 60 FPS 単位で表示更新するまでの、今回メインウインドウサイズとなる 1000 x 800 x 24 Bit 色（ 3 BYTE 色 ）への表示内容を編集する Alloc 領域用（ 2.4 MB 分メモリ確保 new 用 ）になる。
HBITMAP 型変数は、今回例のように DIB に BMP データを使うだけなら Microsoft 仕様の慣例的・初期設定的な使い方しかしないためそれほど注意点も無く、HFONT 型変数の方も今回例としてはそこは同じになる。
＜ 赤 プロジェクト共用変数および定数宣言 １１ ＞
FPS 観測用の変数群と、メインウインドウ側の状態管理用の変数群。
ここでの MainFrame の概念名が入っている変数群が、FPS の元情報管理側になる。
ここはまず、BMP 情報を管理するここでの ViewBmp 概念と、その表示の仕方の表示個数・伝票手配的な管理および FPS 同期計算をするためのここでの ViewTask 概念の、この概念間は慣れていないと非常にややこしい部分（ だからいくらでも改善余地のある概念整理どころ ）だということも、まず念押ししておく。
ViewTask 概念の方の手続き群による FPS 進行管理の手順としてはまず、FPS 関連を意味するこちらの MainFrame 概念名のある変数で FPS 算出の母体値的な静的（ 大事な意味として順述 ）管理がされているものを、これを元手に ViewTask 概念側が、各表示単位管理ごとの同期計算を常に行うという設計構成になっていて、（ DIB 的な ） FPS 設計では今回例はよく用いられる概念形態になる。
MainState という概念名の入っている変数の方は、全体の状態管理的な意味付けにしているが、今回例のここでの MainFrame 概念も MainState 概念も、構造体化（ とりあえずは変数のみの struct / class 定義化 ）してしまってよい一方で、ただしそこは常に急ぐ必要などはない計画的な見渡し方も重要になる。
上達への弊害に向かわせないためにも、動的性と静的性の概念間について説明しておきたいが、しかしその説明に入る前の注意点も多いため、順番に説明していきたい。
だいぶ前の当ブログの初動 オブジェクト指向の倒し方 ０１～１１ の方で指摘している（ あちらはプロジェクトデータなどの具体例がない概要説明のため、その疑問に至っていない時点で伝わりにくい ）こととして、オブジェクト指向側のその元締めたちなり支持者たちなりによる次の段階の概念整理（ 概念間整理向上の立証。その概念規律を用いることによる再細分化と再集約化の概念間最適化・段階管理化 ）の検証努力（ ＝ 等族義務の果たし合い ＝ 上同士視点の上方修正の手本の作り合い ）など一切ない無神経・無関心・無計画な規律絶対のたらい回し合いが３０年近く続けられてきたことを理由（ 上達・上同士視点の原本になるような概念整理に何の貢献もしていないことの指摘を目的としていたのが オブジェクト指向の倒し方 ０１～１１ ）に、今回 GraphicBuildTrial プロジェクトでもクラス手続き化はしない方針での紹介にしている。
当ブログで０４章までに、ここ３０年の Microsoft としての Windows 標準 API 側の概念整理史的な変遷・経緯を説明してきたこととして、オブジェクト指向（ Ｃ拡張側つまりＣ＋＋ ）とはむしろ距離を置いている Wnidows 標準 API 側（ Ｃ原点回帰側 ）では、64 Bit 移行期後も Wnidows 標準 API 側 としての改善余地（ 敷居規律。上同士視点の上方修正に関係 ）に対する状況回収的・検証的・旧廃策的な概念整備による統廃合努力が続けられてきた（ 苦慮しながらの Microsoft のその概念整理の姿勢は、上達への教訓参考として非常に重要だからこそ０４章までに説明した ）一方で、ではオブジェクト指向側はそこはどうだったのかといえば、いくらでもあったはずのオブジェクト指向側の改善余地（ 次の段階 ）に対する検証努力をオブジェクト指向側はここ３０年ろくにして来なかったことがはっきりしている。
Windows 標準 API 側では、構造体の中に構造体（ または不特定型の配列番地など ）が内在している場合もあるＣ以来の情報概念まではあるが、しかしオブジェクト指向側（ Ｃ＋＋側 ）の方の、構造体手続き設計以前の（ クラス関数設計以前の ）変数のみの構造体継承の上位下位（ 親クラス子クラス ）概念すら、Windows 標準 API 側も Windows CRT 側もその概念の導入など一切して来なかった、すなわち変数のみの構造体（ struct / class ）であっても Windows 標準 API 側から見てオブジェクト指向側の情報概念の足並み（ ※ 注 ）にそろえる利点などないと見なしている、すなわち概念整理の参考に全くならないと見なしていることが、この経緯だけでも（ Microsoft Learn 公式でいつでも誰でも確認できる Windows 標準 API 側と CRT 側の入出力情報型を見渡せば ）はっきりしている。
機械語側もそこは同じく、CPU の 32 Bit 化にしても 64 化にしても、オブジェクト指向側の情報概念が参考にされた拡張というものも、これまで一切されて来ていない。（ オブジェクト指向側の都合をコンパイル側がＣ基準に置き換えてマクロ化しているのみ ）
※ 注 ＝ オブジェクト指向側（ Ｃ＋＋側 ）では、構造体Ａと構造体Ｂを継承した構造体Ｃに対し、構造体Ｂの部分だけを抽出的に特に手続き間（ Ｃ関数間／Ｃ＋＋クラス関数間 ）で参照したい場合などで、仮想継承が含まれた場合はバイトズレのオブジェクト指向側の不都合もあるからこそ情報構造体Ｂとしてのキャスト・見なし参照をし直さなければならないというオブジェクト指向側の情報概念の足並み。オブジェクト指向側はのちに、その参照構造体が仮想継承が含まれているか含まれていないかを判定する機能などを追加したようだが、いずれにしても特に手続き間で参照し合う場合などは、それがどのような概念で構成された構造体なのかも、どのような継承関係なのかも、その想定概念の事前の確認無しでは即座に判別することはできない。つまりオブジェクト指向（ Ｃ＋＋ ）を使っても使わなくても結局は、手続き間における引き数名と引き数想定値の概念整理、変数名と変数想定値の概念整理、定数名と定数想定値の概念整理が重要なのは構造体変数（ struct / class ）の使い方でも同じ、どのプログラム言語／開発環境でも共通していえるまずはデータ設計優先（ 入力敷居優先 ）の概念整理の見直し（ 自分たちの段階管理といえる上同士視点の上方修正の手本の作り合い ）を面倒がらない積極姿勢が上達の基本であることに変わりはない。オブジェクト指向側（ Ｃ＋＋側 ）はオブジェクト指向側としてのそうした概念整理の手助けになるような手本的な検証努力など一切してこなかった（ オブジェクト指向側でされなければならないその等族義務の手本の果たし合いなど一切されなかった ）ことははっきりしている。ここは教育機関絶対と全く同じで、改善余地などいくらでもあるはずのその規律絶対のアルゴリズム（ データ設計軽視の出力観 ）の旧態のままの不都合の正しさの足並みをデータ設計側（ 入力観 ）に強要し続ける低次元体質が３０年以上改善されてこなかった。その上同士失格の怠慢の顔色のたらい回し合い・厳しさの向け合いは、各所・各当事者それぞれが次の段階に進むために自分たちでしなければならないはずの自分たちの改善余地（ 自分たちの上同士視点の上方修正といえる自分たちの規律敷居 ）に対する概念整理（ 自分たちが用いる概念名・書類管理性からのＩＳＯ９０００系善用といえる年期計画的な履歴管理・段階管理・階層管理 ）へのあり方を妨害させ合うことに（ ＝ 自分たちの可能性を自分たちで潰し合う低次元同士であり続け合う下の作り合いの巻き込み合いに ）しかならない。データ設計優先の本来の概念整理で旧新の統廃合努力をしてきた大元側の Windows 標準 API 側、CRT 側（ Ｃ原点回帰側 ）の方から見れば、いくらでもあるはずの自分たちがしなければならないそうした改善余地への向き合いに反し続けて３０年以上改善してこなかったオブジェクト指向側（ Ｃ拡張側つまりＣ＋＋側 ）の再細分化不足・再集約化不足のままのだらしない情報管理体質になぜ合わせなければならないのかという関係性が、そのまま当ブログ筆者の姿勢になっている。
※ 何に対する次の段階に向けた上達でも同じことがいえる基本として
木を見て森を見ず ＝ 当事者軸・自己責任性を理由に、主体軸・社会的責任性についての年期計画的な式目交流規律など一切確認し合おうとせずに完璧主義だのできる訳がないだのそんなことをしようとする人間などいる訳がないだのと一方的にうやむやに否定し始める自力信仰一辺倒
森を見て木を見ず ＝ 主体軸・社会的責任性を理由に、当事者軸・自己責任性についての年期計画的な式目交流規律など一切確認し合おうとせずに何を勝手なことをしているんだだの裏切っただのどうせお前も自分のことしか考えていないんだろうだのと一方的にうやむやに否定し始める他力信仰一辺倒
の厳しさをいきなり向け合いたがるばかり、いきなり下を作り合いたがるばかりの上同士失格の怠慢の顔色の窺わせ合い（ ただの性善説放任主義・ただの偽善憎悪・ただの老害浪費の向け合い ）の典型的な愚かさだらしなさに陥りがちな、まずはその自分たちの改善余地（ 選任評議的な論述整理性や議事録処理性がもたれた履歴管理の手本による式目敷居の更新観 ）の向き合いからをそれぞれ最優先に、次の段階に進むための敷居交流規律の手本の作り合いから始める前提の上同士視点のあるある話をここでしているだけに過ぎない。
ここで、データ設計でもアルゴリズム設計でも関係する動的性と静的性の本題に戻るが、これは説明が難しいためどれだけ伝わるかどうか解らなくても大事であるため、章ごとでも追って説明していきたい。
この動的性と静的性も最終的には、当ブログでこれまで推奨してきたデータ設計側の想定計画優先で関連を何度も見直していくことを面倒がらない基本を続けていけば自然に健全に身につくようになるが、上達つまり以前よりもより良い整理方法の確認を自身で重ねるからこその、むしろ今後気を付けなければならない注意点も改めて解るようになっていく（ 履歴の再細分化と再収容化が進んだ分だけ式目規律も改良されていく ＝ 次の段階への自己等族統制が進んでいく ）ものでもあり、だから自分たちでできることを増やしていく幅（ 更新観 ）も広げられるようになっていく、と前置きしておく。
まず、静的性はいわば木、動的性はいわばその木に付随する葉や枝や実、といったような表現がされがちだが、ここは慣れないと本当にややこしい所で、そのような例え方で止まってしまうとかえって誤認の元になってしまうのが難しい所になる。
オブジェクト指向側はそこに全くの無神経・無関心・無計画な、いきなりの誤認例としてよく出したがるのが自動車に例えた
車体の変数群とその手続き群のクラスＡ（ Ｃ＋＋構造体Ａ ）と、エンジンの変数群とその手続き群のクラスＢ（ Ｃ＋＋構造体Ｂ ）と、タイヤの変数群とその手続き群のクラスＣ（ Ｃ＋＋構造体Ｃ ）を結合（ 継承 ）した、それが全て組み合わさったクラスＤ（ Ｃ＋＋構造体Ｄ ）が自動車
だという、このようなここ止まりの説明は誤認の元でしかない、言いたいことは解るがこれで説明できている気、伝えられる気、解った気になり合おうとしている時点で自分たちで概念間整理などろくにしてこなかっただらしなさの態度丸出しといってよい。
これはもちろん、車ならスピードメーターが、ハンドルやバックミラーが、エンジンオイルが、ペダル駆動が、エアコンが、燃料や電力の供給の仕様が、といった細かいことは置いておきの概念整理の参考を巡る指摘になる。
まず情報管理（ 変数想定計画 ）の視点では、動的側は燃料や原料など議題元の仕入れ的・入力的データ群、静的側はそれらを加工だったり調理だったり配置だったりを行う工程においての主軸処理用データ群 と大別はできるが、ここは間違っても教育機関絶対どもやオブジェクト指向の規律絶対どものような典型的な「これはこういうもののはず！ こうすることが正しいはず！」丸出しの固定的な丸覚えなどしようとしてはならない、そこに陥ると次の段階に向けた自分たちの上達から遠のく一方の、後から改善を困難にしていく一方の偽善曲解を重ねる非履歴管理的な弊害足枷の作り合い（ 上同士失格 ）の原因となる。
ここはざっとでもいいため、これまではこういう場合のこの箇所は［ 動的性 ７：３ 静的性 ］、この箇所は［ 動的性 １：９ 静的性 ］という感じだな、と、前回分・今回分・次回分以降ごとでのそうした成分分析的な傾向の見渡し方を軽視してはならない、そこは常に怠ってはならない。
次の企画が、以前からの拡張企画にしても、そうでない別企画にしても、企画事情でその成分事情が箇所によっては以前とガラっと変わってしまう（ 変えなければならない ）場合などいくらでもあるからこそ、だからこそそこを常に見直し続ける基本を怠ければ怠けるほど 以前・今まであのやり方でうまくいったはずだから、今回も全く同じやり方にすれば良いはず（ なのに、それが可能／不可能の絶対のはずなのになんでそれに逆らうんだ！ そんなこともワカランノカ！ ）という低次元体質の態度丸出しにいとも簡単に陥ってしまう原因となる。
例えば、食品売り場の店舗をいくつか経営している例の場合、大まかには仕入れる食品が動的データ、販売店の建物の仕組みや従業員の各担当の仕組みに関するものが静的データという成分傾向にはなるが、大手飲食店でもよくあるように、卸業の内のいくつかは自社内（ 例えば食肉については自社内の１００％出資子会社が請け負っているなど。自社ブランド品 ）で維持する場合もあり、販売店の視点から見たら仕入れる食品は動的データ性は高くても、社全体のデータ管理で見た場合だと、扱う分野によってはその中にまたその仕組みの静的性質が強くなる箇所も当然出てくる。
また、店舗経営の視点では従業員の務めとしての性質は静的データ的でも、その人員確保や入れ替わりについては動的といえ（ 店舗方針の売り上げ傾向管理と同じく、店舗方針に合う合わないの従業員の傾向など。店舗が維持できなくなる要因のひとつに、実は利益自体はうまくいっていても、地域事情で従業員の確保に苦しんで労務難でやむなくその店舗を閉業したり移転したりせざるを得ない場合もある ）、モノもヒトも年々の少しずつの世の変遷の傾向も管理していかなければならない各概念間管理（ 式目敷居の更新観 ）の質のことも考えていくと、教育機関絶対どもやオブジェクト指向の規律絶対どものように力関係任せに １０：０ で仕分けっぱなしに上同士失格の怠慢の顔色をたらい回し合えば・厳しさを向け合えばいいというものではないのは、何にでもいえる話になる。
そういう所を念頭に入れながらの今回議題 GraphicBuildTrial では、ViewBmp や ViewTask の概念名があるものは動的性（ 材料的や手配伝票的な変数の意味 ）が強く、MainFrame や MainState といった概念名があるものは静的性（ 主軸の仕組みを回すための変数の意味 ）が強いといえるが、動的側でも静的性はゼロでないように、静的側も動的性はゼロでないことに注意になる。
※ 上記 ViewTask の紹介で、ViewTaskBuild 手続きだけＢ扱いしているのは、動的性の強い ViewTask 概念内での静的（ 主軸的。集計的 ）な意味合いの手続きであるため。
例えば、Microsoft の見本を元にしている WndProc 手続き自体は静的性（ 主軸性 ）が強いが、例えば DIB 用ウインドウと、ダイアログ用（ AssistKeep プロジェクトまでの、Windows のおなじみの入力項目やボタンやリストなどの構成を前提としている画面 ）のウインドウの２つを表示する仕様にする場合、ダイアログ側の WM_ 系イベントメッセージ管理も WndProc で併用するのもいいし、そうではなく DialogProc という手続きを別途用意して、ダイアログ側についてはそちらで処理分けする作りにしてもよく、この例が静的側における動的性になる。
データ設計優先の基本から見渡せば、動的性と静的性の成分分析的な設計が優先されなければならないからこそ、だからオブジェクト指向の規律絶対どもが例えたがる上述の自動車の例のような、動的性と静的性の概念整理を完全無視しているような説明は弊害でしかないといってよいのである。
人が作ったプログラムを読み解こうとすること自体がただでさえややこしく手間取りがちからこそ、ここでの動的性と静的性の大事な意味にまず間違いがないよう、ここを念頭に入れながらでないと、今回議題 GraphicBuildTrial の構造が全く解らないままになる。
０５章 AssistKeep までは、ただ画面の作り方や Microsoft Edge の補佐をするだけの、動的性と静的性の概念はそんなに意識しなくてもよいような内容だったが、DIB プログラムの場合はこの基本をよく念頭に入れながらでないと、本当に何をやっているのかが、次回以降はなお全く解らないままになる。
今回からのちょっとした拡張版を予定している次回議題 GraphicBuild の方と、今回とで比較することで、ここで説明している動的性と静的性の大事な意味を伝える手助けになるのではないかと、当ブログ筆者は見ている。
ここで注意しなければならないのは、オブジェクト指向側（ Ｃ＋＋側 ）はＣ拡張を謳っておきながら大事なこの動的性と静的性の概念整理を手助け・補佐するための機能など一切追加していなければその等族義務も何ひとつ果たしてきていない、まさに教育機関絶対の構図と全く同じでオブジェクト指向の規律絶対の足並みにそろえることがさも動的性と静的性の概念間整理が得られるかのように錯覚させ合い、自分たちで次の段階に進むことをできなくうやむやにさせ合うことしか能がなくなる低次元同士であり続け合わせる教義詐欺・偽善誇張が繰り返されてきただけに過ぎないのが実態になる。
オブジェクト指向は所詮は、誰かが整理したフレームワーク的（ その目的に整理した仕組み ）概念を共通認識的にオブジェクト指向の規律に落とし込んでそれを共用（ フレームワーク化 ）しようとするためのものでしかなく、当ブログ筆者としてはオブジェクト指向の試み自体は否定しないが、他の場合の概念間整理と何の関係もないその足並みにそろえることが概念間整理をすることになるかように錯覚し続ける愚かさだらしなさ（ ＝ 分離させるだけ分離させるのみ、結合させるだけ結合させるのみの、そこを快適に整備していくための手助けなど何ひとつしていない、何の役にも立っていない余計な弊害規律の手間をただ増やすのみ ）は否定せざるを得ない、といった所になる。
自分たちで概念間整理（ 自己等族統制 ）した訳ではない同士のはずが、誰かが作ったフレームワークにただ頼ってそういう結果が得られる目先の利害だけをただ丸覚えしたに過ぎないものを頭が良くなった気にいい所できている気に解った気になり合い、そのフレームワーク（ その中の可能／不可能 ）外のこと（ よそのこと道義領域外のこと ）にケンカ腰に厳しさを向け合い下を作り合い調子に乗り合おうとする、改善余地だらけ丸出し（ 良い悪い以前の境界・段階・階層の敷居管理のための自分たちの上同士視点的・選任評議的な式目敷居規律も自分たち作れていない ）の自分たちのその愚かさだらしなさを自分たちで直せたことがない上同士失格の構図はまさに教育機関絶対の姿そのもの、次世代敷居交流規律荒らしと見なされて機銃掃射でハチの巣にされて当然の法賊行為・老害愚行といってよい。
＜ 赤 プロジェクト共用変数および定数宣言 １２ ＞
ここは定数だが
WNDPROC_CYCLE 5001
は、Windows 標準 API の SetTimer を使って WM_TIME を発行させるためのＩＤ値になる。
このＩＤ値は、その開始の SetTimer とその終了の KillTimer とで一致していれば、値自体は 0 や 1 だったり 100 だったりでもよいが、ここでは特殊値的な意味でこの値にしている。
想定計画として重要な定数名と定数値の工夫は、このような役割分け・処理分け的な定数値の場合は例えば、1000 から始まるものがこういう意味、1500 からが 1000 から始まる関連の第２概念、2000 から始まるものがこういう意味、といったように設計の規模が大きくなってくるほど、そのように数値自体にも意味付けもしていくようにすると、概念整理しやすくする手助けにできるため重要になる。
SetTimer の WM_TIME は、今回の DIB 更新処理の都合のような、定期的なループが行われるようにするための Windows の特徴的な仕様になる。
※ 64 Bit 以後の Visual Studio のＣ／Ｃ＋＋を使う分には、今となっては特に考慮する必要はない Windows 標準 API 史的な余談になるが、まず当ブログ筆者は、64 Bit コンパイルの方で DIB 設計をしたのは今回が初めてになる。今回、統合前 32 Bit 時代（ Windows NT 4.0 / Windows 2000 時代 ）に使ったことがあった DIB がどうだったかを思い出しながら、できるだけ解説用になるよう変数計画を見直しながら作ってみた所、概要としては統合前 32 Bit 時代と全く変わっておらず、しかし DIB を使うにあたっての当時の厄介な仕様がだいぶ改善されていたことに驚いた。統合前 32 Bit 時代の DIB の走査線（ 画像データ配列 ）は、左右は BMP と同じだが上下が逆だったため、BMP データ配置から見て上下を逆向きに DIB 側にデータ送信をしなければならなかった仕様が、その上下逆さまが無くなっていた、つまり BMP データと同じ走査線に DIB 側が合わせるようになっていたため、これだけでもだいぶ楽になっていた。ただし Left と Top の内の DIB 側の Top の概念は以前通り逆のままのため、そこは DIB 設計者側が以前通り調整計算しなければならないため注意になる。それともうひとつの大幅な改善がこの SetTimer の WM_TIME メッセージについてで、厳密には GetMessage / WndProc の改善だが、統合前 32 Bit 時代のコンパイルでは、０５章 AssistKeep までのような、マルチスレッドは特に使わないままの設計をすると、WndProc を通して重い処理による遅延があったり、特に WndProc を介して MessageBox（ Windows おなじみの古くからの、終了連絡や注意等でよく使われてきたメッセージボックス ）を使うと顕著だったこととして、ダイアログ側の自動描画停止のドン詰まり症状が起きる問題も大幅に改善されていたことにも、大いに驚いた。SetTimer による WM_TIME 発行が自動的に半マルチスレッド化してくれるようになったことで、（ 全てではないにしても ）かつての厄介だった描画処理停止のドン詰まり症状を起きにくくするよう、 WM_TIME（ GetMessage / WndProc ）の仕様がだいぶ改善されていた。統合前 32 Bit 時代当時は、非ＭＦＣの場合はこの問題のためだけにわざわざマルチスレッドを発行しなければならないややこしい設計をしなければならなかった、DIB の仕様にしても不便だった当時の仕様は「やっぱり当時のあの仕様はのちに Microsoft としても、欠陥に近い仕様だと認識をするようになったんだな」と当ブログ筆者は今回理解した。このように Microsoft は、改善した方がよいと見ている箇所の検証努力もしており、時間はかかったとしてもその等族義務の果たし合いはしている方だからだいぶ良い方といってよい。今回でこれら Microsoft の改善を確認するまでは統合前 32 Bit 時代の認識のままだった当ブログ筆者は、当初は DIB 設計の説明をする上でマルチスレッド発行の説明もしなければならないと思っていたが、当面は、自動的に半マルチスレッド化してくれるようになった WM_TIME を使っての DIB 設計の説明をしていくことにした。
WINDOW_WIDTH 1000
WINDOW_HEIGHT 800
については単純に、今回の DIB の基本の大きさを示す基準値で、GraphicBuildTrial では BMP を、大まかに背景 BMP と前景 BMP との概念に分け、背景側はこの値を前提とする作りにしている。
以上が、手続きの前方宣言と、構造体宣言と、共用変数宣言（ どの手続き／関数／プロシージャからも参照できるグローバル変数 ）と定数宣言の説明になる。
プログラム側の要点的な説明もしたい所だったが、ブログ機能の字数制限の都合で、これだけでも概要は伝わると思い、今回はここまでに区切ることにした。
プログラム側の要点については次回予定０７章 GraphicBuild の方で改めて説明することにする。