Windows C/C++ 検証報告プロジェクト：初動 WindowOrigin 2025/12/04
※ ここでは、オブジェクト指向の規律および、マイクロソフト独自仕様が濃すぎてもはやＣ／Ｃ＋＋ではないリソース／マクロはできるだけ除外しながら動作確認、正しいかどうか以前の前段階としての Windows プログラムを介しての Microsoft の内部的な仕組みの理解のための検証報告が、ここでの主目的となる。
※ ここでは、Windows 10/11 のＰＣが対象であること、０２章で紹介した Microsoft Visual Stutio Community 2026（ 無料版 Visual C++ 開発環境 ） のインストール環境を前提に、話を進めている。
※ ここではキレハシ説明ばかりなものは避ける、特に、なぜそうしたのかの経緯が全く読み取れない箇所もできるだけ排除、できるだけ実際の動作確認もできるよう、検証報告の内容に応じてプロジェクトファイルまるごとを順次アップロードしていく。今回では下述にプロジェクトファイルのアップロード有り。
※ 当ブログでは 統合前時代 という言葉を今後もよく使うことになるため事前に説明しておくと、これは 95/98 系と NT 4.0 / 2000 系が統合されることになった Windows XP よりも前のそれらの時代のことを指す。当ブログ筆者は NT 4.0 / 2000 の方での関わりが強かったことで 統合前 32 Bit 時代 といういい方をしている場合は、32 Bit 化本格発足となった NT4.0 以来の Windows API（ 32 Bit 本格化当時の Windows 内部標準仕様 ）の意味が強い。
今回は、当ブログでの初動プロジェクト WindowOrigin ということで（ この名称は Windows の仕様名等でない、当ブログ筆者による題名 ）紹介していきたい。
今回、当ブログ筆者としてのＣの書式規律等に触れようと思っていたものの、検証報告用ソースコードの準備内容が、次回以降の検証報告プロジェクトの方がその紹介がしやすい内容だったため、そちらについては次回以降に追って紹介していくことにする。
今回、初動プロジェクトということでその意図としてまず、前回０２章で当ブログでの出発点だと紹介した、新規プロジェクト作成の［ Windows デスクトップ アプリケーション ］からの、そこからの初期準備的な添削（ てんさく。追加・修正・削除 ）の紹介、というよりも「これも、これも、これも使わない」の削減が中心のそぎ落しの概要・理由を伝える目的が WindowOrigin だということで、紹介していきたい。
冒頭から説明してきた通り、当ブログでの Windows プログラムに関してはできるだけ、Ｃと、統合前時代の Windows の機能中心で紹介していくために、Microsoft 独自仕様の内部リソースとオブジェクト指向の規律はできるだけ排除していく方針だからだが、Ｃの書式規律等についての説明は次回以降となるため、Ｃ自体に不慣れな人だと今回の説明は少し難しいかも知れない。
Ｃに関しては次回以降も順を追って説明していくため、今回に関しては（ まず初期準備を進めないことには当ブログでのＣの説明もできないため ）何をいっているのかよく解らなくても、当ブログ筆者がどのような判別の仕方をしているのか、今回何がされたのかの概要だけ見てもらえば（ 後でまた見返してもらえば ）よい。
本題に入り、前回０２章で紹介した、［ Windows デスクトップ アプリケーション ］の、あの見本のままの
この未編集状態から、当ブログ筆者がそこから何を削減するのかを、説明していく。
ここから、０２章で紹介した［ Windows デスクトップ アプリケーション ］で新規作成からの未編集状態のプロジェクトが Visual Studio に表示されている状態を前提に、ここではそのプロジェクト名が WinProgTest である場合の、そこから削減対象の概要を説明していく。
まず、右側のソリューションエクスプローラーで
下部タブがソリューションエクスプローラータブになっていなかったり、中が展開されていない状態に戻っていることもよくあるため、その場合は各赤丸を押してこのように展開、プロジェクト名の cpp ファイルをダブルクリックして表示／編集状態にする。
見本のこの、プロジェクト名.cpp のメイン部分は、
ヘッダーファイル（ include の部分 ）の慣習の若干の変更と、64 Bit 化までの変数型の若干の変更がある他には、内容自体は統合前 32 Bit 時代（ ２０２５年現在から３０年近く前 ）と全く変わっていない。
まず、１の赤枠の部分だが、ここではインスタンスハンドルの保有用の HINSTANCE 変数と、Microsoft 独自仕様の内在リソース側（ プロジェクト内リソース仕様。意味も順述していく ）に設置してある２つの文字列情報を取得するための WCHAR [ 100 ] 変数が２つ設置されているが、当ブログ方針ではこれらは削除対象になる。
まず、Windows プログラムは操作面における設計としては、主にウインドウハンドルおよびメッセージによる通知中心に設計していくのが特徴で、次章以降でも説明をしていく。
プログラム開始時に各割り当てられるインスタンスハンドルについては、常に通知されるウインドウハンドル情報を元手に、標準 API の GetWindowLongPtrW（ C:\Windows\System32 の user32.dll。統合前 32 Bit 時代の旧 GetWindowLong から概要はほとんど変わっていない ）を使えばいつでもインスタンスハンドルの取得は可能であるため、何か特殊な設計の予定でもない限り、普段はインスタンスハンドル情報を保管しておく必要はない。
GetWindowLongPtrW 関数 (winuser.h) - Win32 apps | Microsoft Learn
GetWindowLongPtrW は次章で使用しているため、改めてそちらで紹介する。
２の赤枠の方で、LoadStringW によって内在リソース側からの文字列情報の取得が行われるが、この見本ではマイクロソフト独自仕様の濃いその使い方例を案内する目的でこうした設置があえてされているだけで、こうしなければならない重要な理由自体はここには全くないため、当ブログでの Windows プログラムの方針として、Microsoft 独自仕様が濃すぎる内在リソースはできるだけ使わない方針として、これらも削除する。
実際の削減後の様子はのちほどとし、このように削減していく理由からまずざっと列挙していく。
次に
３の赤枠の LoadAcceleratorrs は、プロジェクト内在リソースからメニュー群情報を取得し、メインウインドウにメニュー群仕様を反映させる処理、４の赤枠の TranslateAccelerator ではメニュー群の操作反応（ メッセージ ）を通知するための処理だが、当ブログでは、Microsoft 独自仕様の濃いこれら内在リソースはいったん切り離すという、まずはできるだけＣと Windows 標準 API に集中したいということで、これらも削除する。
つまり、当ブログでの Windows プログラムの出発点としては
メニュー群の撤去および、その中のバージョン情報ダイアログも撤去の、Ｃの逸脱が強い Microsoft の独自仕様をできるだけ撤去、ただ右上にＸボタンがあるのみのまっさらなウインドウのみの状態にすることが、当ブログでの出発点だと伝えること、Microsoft の見本からのどのような経緯でそうしたのかを伝えることが、今回の WindowOrigin の目的となる。
Windows としての基本的なこのメニュー群仕様は有用だとは思うが、内在リソースの Microsoft 独自仕様が少しややこしいため、いったんＣと Windows 標準 API の使い方に慣れてからにでも、使いたい人は後で改めて［ Windows デスクトップ アプリケーション ］による新規作成で自動作成されるリソースファイルとこれら形式を参考に、使うようにするとよい。
バージョン情報ダイアログ画面 などは内部リソース複合のオブジェクト指向強要のＭＦＣ（ Microsoft Found Class ）であるため削除するが、一応、それら内部リソースの様子も少し紹介しておきたい。
右側のソリューションエクスプローラーの
このプロジェクト名の rc ファイルが、Microsoft 独自仕様の強い内部リソースファイルで、これをダブルクリックすると リソースビュー タブが出現する。
赤丸部分で展開していくと、各項目の見本情報が確認できる。
それぞれの中の、IDC_PROGTEST、IDD_ABOUTBOX、IDI_SMALL および IDI_WINPROGTEST、IDC_WINPROGTEST、String Table これらをダブルクリックすると、左の編集側にそれぞれ表示されるが
IDC_PROGTEST
IDD_ABOUTBOX
IDI_SMALL および IDI_WINPROGTEST
IDC_WINPROGTEST
String Table
左側の編集部でそれぞれ編集できる機能が Visual Studio に搭載されているが、当ブログ説明ではこれらはアイコン情報のみを残して、後は全て削除する。
ここでは具体的には触れないが、概要を少しだけ説明しておくと、まず、右側のリソースビューの方で、その枠内のどこでもいいから右クリックすると
このようなポップメニューが表示されるため、リソースの追加 をクリックすると
どのような種別のリソースを追加するかの画面が表示され、ここから種別単位の項目を新たに追加していくことができる。（ 当ブログにおいてはこれらは使わない ）
ここでは具体的な説明はしないがついでの話として、ＭＦＣ側およびドットネット（ 意味は順述 ）の構造的な概要にも少し触れておくとまず、リソースビュー枠のダイアログ画面を指す IDD_ABOUT の項目をダブルクリックしてその編集表示をして、そのすぐ左側にある ツールボックス をクリックすると
このような部品群一覧が表示されるため、ここの右上の ピン留め をクリックすると
このような画面配置にできる。
※ ツールボックスを間違えて Ｘ を押して見失った場合は上部メニュー群 表示（Ｖ） 内 ツールボックス（Ｘ）
（ 当ブログにおいてはこれらは使わないが ）この部品一覧の各項目をクリックすると、右側のダイアログ画面編集にその部品が追加できて、マウスで部品の配置位置や、ダイアログ画面を含む各部品の大きさ変更もマウスで操作、部品をクリック選択状態で Delete キーを押すと削除、といったように、ここで画面構成の配置と、それぞれの部品のある程度の初期設定を行うことができて、それが内部リソース情報が自動的に構築されていく、という仕組みになっている。
便利そうに見えるが、初期配置が楽だからといってこれを使い始めると Microsoft の独自仕様およびオブジェクト指向強要ＭＦＣに振り回され、内部リソース側との境界も訳が分からないままに陥るため、そうならないためにもここでは内部リソース仕様は最小限のものしか使わない。
この仕様に興味がある人も、とりあえずは当ブログ筆者による、Windows プログラムがどういったものなのかをざっと把握できた後に、興味があれば後で改めてこちらにも触れてみる、ということでも遅くない、遠回りでもその方が無難だと推奨する。
ＭＦＣ視点の部品一覧の様子に触れたついでとして、ＭＦＣかどうかに関わらずの Windows の構造概要も少し説明しておくと、まず、Visual Studio の上部メニュー群の ヘルプ（Ｈ） の バージョン情報（Ａ） を押すと
ここに ドットネット フレームワーク と書かれている。
どういうことかというと、Visual Studio からいったん Windows のおなじみの機能の方に視点を変え、ファイル操作をするための エクスプローラー だったり、ＰＣ環境を確認するための デバイスマネージャー の画面だったりの、例えば
この画面は Windows 10 でのデバイスマネージャー関連の画面だが、ここにそれぞれ使用されているウインドウ上部メニュー群だったり、各デバイスのツリー表示だったり、全般／ドライバー／詳細／イベント／リソース 各切り替えのタブ表示だったり、ＯＫ キャンセル を始めとする各ボタンだったりのそれぞれのこうした部品群というのは、例えば Windows 10 から Windows 11 になった際に、デバイスマネージャー画面で使われる各部品が見た目も機能も全く変わっていないように見えても、それぞれの各部品ごとの内部的な更新（ バージョンアップ ）も年々行われていて、それがドットネットのバージョン情報になる。
Windows 95 の方はどうだったか覚えがないが、Window NT 4.0 の方ではＳＰ６（ サービスパック。ＯＳの改善更新。NT 4.0 では６が最終となった ）時点で .NET Framework 1.1 が標準搭載扱い（ NT 4.0 の発足当時は 1.1 はできておらず、何年後かに、NT 4.0 も標準搭載的な認知で 1.1 が追加される形となった ）されている。
少しややこしい話だが、さらに
こちらも Windows 10 での画面だが、Windows NT 4.0 で標準搭載されていた当時の 電卓 と ソリティア のそれぞれのファイルを、64 Bit ＯＳである Window 7 や 11 の方にもってきても、このように動作する。
これは、64 Bit 化の普及主流となった Windows 7 あたりから、Visual Studio も 32Bit / 64 Bit 両方のコンパイラが標準搭載されるようになっての、その２種類の動作および、32 Bit のみのコンパイラしかなかった（ さかのぼれば ）統合前 32 Bit 時代との、その計３種が、64 Bit ＯＳ以降でも一応は動作対象であることを意味している。（ Visual Studio Community 2026 で作られた exe の下位互換として Windows 7 でも動作することは確認できている。VISTA でも動作するかも知れない。一般普及のＸＰでは動作しないが、一般向けでなかった 64 Bit 版ＸＰなら動作するかも知れない ）
統合前 32 Bit 時代の Visual C/C++（ Microsoft Visual Studio のコンパイラ ） で作成されたソフトウェアも 64 Bit Windows でも動作対象とはいっても、ただし実際は動作しないソフトウェアの方が多いと見てよい。
古いコンパイラで作られても 64 Bit Windows でも動作するソフトウェアというのは、Microsoft 生粋の内部仕様に準拠して設計されているという前提に加え、98 / 2000、XP と次のＯＳに進んでいく過程で、Microsoft 内での規格が廃止されたり変更されることもなかった仕様だけで設計されているものしか動作しない、例えば Mircosoft 製でない DLL ファイルを多用しているもの（ Microsoft の内部仕様の変更や廃止に対する保守・再配布がされていない、当時は動いていた、そのＯＳまでしか動かない DLL や EXE ）だったり、 また Microsoft 製の EXE、DLL であってものちに Microsoft 内におけるその規格が廃止・変更された機能を使っているソフトウェアだと動作できない。
※ 統合期であるＸＰを迎えるまでに、統合前 32 Bit 時代以来の内部仕様についての変更や廃止がなかったものについては、ＸＰ以後は変更はほぼされないと見てよい。つまり、その古いソフトウェアに需要があるのかどうかはともかくとして「その古いソフトウェア（ EXE や DLL ）はＸＰでも動作していたのなら」を分岐点的に、以後の新たな Windows でも動作し続ける可能性が高い。ただしその旧 32 Bit ソフトウェア／アプリケーションについての動作保証にしても、この事情（ 当ブログ筆者がたまたまその経緯を見渡していたからできたこの説明 ）にしても Microsoft はこれまで具体的な告知をして来なかった、だからこの旧 32 Bit 動作仕様は次の Windows ごとでいつ廃止されてもおかしくなく、廃止する予定があるのかどうかも不明。
この話は当ブログ説明においては重要で「ここでは、64 Bit 以後も大して変更はされていない、統合前 32 Bit 時代以来の Windows 機能のみをできるだけ使う（ その方が Windows の根底仕様の理解がしやすい ）」という原点回帰を前提にしている。
つまり上記の、Windows 10/11 でも動いている電卓やソリティアで使われている仕様を用いて動作確認していく（ ソリティアは見た所、自由型画像操作の DIB 仕様が使われているため、そちらも順を追って紹介予定 ）ことが、ここでの狙いになる。
ここで Visual Studio に視点を戻し、当ブログでは使わない前提で Visual Studio としての概要としてもう少し説明しておくと、Visual Studio 側の上部メニュー群の、ツール（Ｔ） 内の ツールボックス アイテムの選択（Ｘ） という項目をクリックすると
ここからドットネット関連や、ドットネットという枠組みではない Windows に内在されている他の機能も選べるようになっていて、これらは画面構成関連だけでない、ネットワークに関するものや、例えばプリンターの印刷関連を補佐してくれる機能だったり、ＤＯＭ（ ブラウザ関連機能 ）もたぶんあると思われる。
当ブログ筆者はこれらを使ったことはないためそもそも説明もできないが、Visual C/C++ からだけでなく Visual java からや Visual Basic からなどでも使えるように（ 補佐してくれるように ）なっているようである。
Visual Studio の基本画面側の方に視点を戻し、
次の話に進めるために、ツールボックスの ピン留め を外し、リソース編集側のそれぞれの画面もいったん全て Ｘ で消し、右側の
リソースビュー から ソリューションエクスプローラー にタブを戻し、今度は、こちらのリソースファイル（ rc ファイル ）の所で右クリックでポップメニューを出し
コードを表示 をクリックし、
この画面が出る場合は はい（Ｙ） で進めると、左の編集側に、リソースファイル内の実コードが表示されるようになる。
ここのリソースコードは、書式自体がもはやＣ／Ｃ＋＋でない Microsoft 独自のマクロ仕様で、だから当ブログでの初期準備では、この大部分を削除する前提となる。
先ほどのリソース編集画面で内容が編集されると（ ダイアログ画面を変更したりドットネットの仕様を用いたりすると ）、自動的にこのリソースコードに反映され、ある程度の初期動作設定もこちらのリソース側で管理してくれる、という仕組みになっている。
この独自仕様の書式が理解できていればだがここからでも直接内容を編集できるが、ここでは特に触れない。
Microsoft 独自仕様の内部リソースについて、経緯として説明しておきたかったため少し回り道になってしまったが、ここでメインの cpp ファイルの方に視点を戻し、wWinMain 手続き（ 関数。プロシージャ ）の次の、MyRegisterClass 手続きについて
これはウインドウを生成する際に、どのような基本情報で生成するのかを Windows 側に通知しなければならないという定番の仕様の部分だが、当ブログの初期段階においては、メニュー群は削除するということで赤枠の６の設定値を、 0（ NULL ）に変更する。
５と７の枠は exe に内在させるアイコン情報で、ここだけは当ブログ説明で内部リソースを唯一使用し、これを除く他の内部リソースは全て削除する前提となる。
内部リソースは全削除したい所だったが、色々試してみたが、exe へのアイコンの内在化だけはこの内部リソース仕様を介さないと内在させられない仕様らしいため、アイコン情報だけはやむなく残すことにした。
MyRegisterClass の次の InitInstance 手続きだが
ここでは手順的には、先の MyRegisterClass 後に、CreateWindowW （ user32.dll ）でウインドウを生成、ShowWindow（ user32.dll ）と UpdateWindowW（ user32.dll ） を使って生成したウインドウを表示する、という基本のみで、当ブログ説明としてはここの概要自体には変更は特にない。
次の、Windows プログラムの操作面における特徴である、ウインドウハンドルとメッセージ通知による操作面の設計で大事になってくる WndProc 手続きだが
当ブログ説明では内部リソースのＭＦＣダイアログ画面は使用しないということで、８の赤枠は丸々削除する。
ここは丸ごと削除する前提の余談になるが、まずこの MAKEINTRESORCE( IDD_ABOUTBOX ) の所が内部リソースのバージョン情報ダイアログ画面の構造情報の指定で、それによって DialogBox（ user32.dll ） という Microsoft 独自仕様の濃いこの手続きを介してバージョン情報ダイアログ画面を表示する仕組みになっているが、ここの case IDM_ABOUT : の部分は
HINSTANCE hIns = ( HINSTANCE )GetWindowLongPtrW( hWnd, GWLP_HINSTANCE );
DialogBox( hIns, MAKEINTRESOURCE( IDD_ABOUTBOX ), hWnd, ( WNDPROC )WndProc );
に変更してやれば、内部リソース側のダイアログ画面用のウインドウハンドルおよびメッセージ通知処理のための
こちらのこの About 手続きを不要に、ここにある IDOK や IDCANCEL の処理を WndProc 内にもっていく、という手法にしてもよい。
内部リソース情報を元手に画面表示させるというこの DialogBox は、表示させるその HWND ウインドウハンドルの取得をさせようとしていない時点で欠陥のようにすら当ブログ筆者には見える。
WndProc と形状はほとんと変わらない About を別途用意しているのは、バージョン情報ダイアログ画面（ ＭＦＣ画面 ）を閉じた際に WM_DESTROY のメッセージ通知が来てしまうからだと思われるが、この見本のようにウインドウの構造自体が単純な場合なら、WndProc に集約する場合は WM_DESTROY 処理の所を
case WM_DESTROY:
{
HWND hWndSearch = GetWindow( hWnd, GW_OWNER );
if( hWndSearch != NULL && hWndSearch != hWnd )
{
// 何もしない
}
else
{
PostQuitMessage(0);
}
break;
}
と改良し、WndProc の WM_COMMAND 処理の所は冒頭で
case WM_COMMAND:
{
HWND hWndSearch = GetWindow( hWnd, GW_OWNER );
if( hWndSearch != NULL && hWndSearch != hWnd )
{
if( LOWORD( wParam ) == IDOK || LOWORD( wParam ) == IDCANCEL)
{
EndDialog( hWnd, LOWORD( wParam ) );
break;
}
}
else
{
．．．元の処理
}
}
という判別の仕方をしておけば、About を不要に WndProc の方だけで完結できる。
ウインドウハンドルおよびメッセージの通知処理用の手続き（ 関数。プロシージャ ）は、ここでの見本のように WndProc と About とで分けておく手法ももちろん有りだとは思うが、画面関係が単純ならこのように、あまり分散させずに集約（ 乱立分散しっぱなしから足並みが揃うのかどうかも解らない後出し共用手続きに力関係任せに強引に従わせようとする解釈の仕方ばかりでうまくいく訳がない、次の段階に対応の最適化に向かう訳がないから、先にできるだけ共通点を統合してからやがて種別ごとに分散させていく構造を常に見渡し続ける心がけに ）してしまった方が良い場合も多い。
こういう所を自分たちで積極的に工夫していく姿勢（ ＝ 見本がそうだからと、何の考えも無しに何でもかんでもそれにただ無条件降伏しなければならない必要などない姿勢 ＝ そういう所を自分たちで解決しようとしない内からＭＦＣやオブジェクト指向の規律に頼り切るようなそのいいなりとねじ伏せ合いの体質を始めると、目先の利害次第のある程度の実現は可能になっても自分たちで敷居改善できなくしていく原因 ）が、後で見直した際の、次の段階に結びつく自分たちでしてきたことの再分離・再整合の考察に役立つきっかけにしやすくなる。
いずれにしても Microsoft の見本にある、内部リソース情報群から画面を呼び出すＭＦＣ都合の DialogBox およびその消去の EndDialog は当ブログでは削除対象・未使用前提であるため、この部分についてはキレハシ説明にさせてもらった。
以上で ＭＦＣ等は使わない、内部リソースの大部分は削除、の経緯説明 はここまでとし、ここから改めて今回の題目である WindowOrigin の紹介をしたい。
今回のそのプロジェクトファイル全体をダウンロードできるよう、アップロードリンクを用意したが、この WindowOrigin.zip 文字列上にマウスを合わせて右クリックの、ポップメニューによる「リンクを新しいタブで開く」を推奨する。
※ ウイルスチェックソフト：スーパーセキュリティ Ver 27.0.52.261 | 2025/12/02 時点最新で確認済み
右クリックポップメニュー リンクを新しいタブで開く で、Microsoft サービスの OneDrive 画面になるため
この画面の左上の ↓ ダウンロード の文字か、中央の ダウンロード の文字かのいずれかを左クリックすると、このファイルがダウンロードできる。
ファイルサイズが 1 MB もないため、ダウンロードの実感などないほど即完了になる。
混乱がないよう一応、Window 11 の エクスプローラー操作でのダウンロードファイルの状況説明もしておくと、まずダウンロードするとそのファイルが
例の ダウンロード 項目の所に保有されるが、Windows 11 の初期設定だとダウンロード項目の場合は、左枠の方の中のツリー表示ができないようなため（ ファイルをダブルクリックすると中の参照はできるが ）、ここでは
ダウンロードファイルを右クリックで 切り取り を押して
どこかのフォルダに、右クリック －＞ 貼り付け でそのダウンロードファイルを移動する。
移動したダウンロードファイルのフォルダを、左側の赤丸の所で展開し、画像にある左側の WindowOrigin を左クリック、右側の中身が画像のように slnx のプロジェクトファイルが表示されているその階層状態で、左側選択のその WindowOrigin の所で 右クリック －＞ コピー を押す。
当ブログ筆者の場合は、C:\FilesVC\ というフォルダで主に Visual Studio の各プロジェクトファイルを管理しているため、ここではそこで 右クリック －＞ 貼り付け をし
これでダウンロードファイルの中の、プロジェクトファイル群が取り出せる。
取り出し後はそのフォルダ内の slnx ファイルをダブルクリック（ そのファイルをクリック選択セルしてエンターキー ）すると、そのプロジェクトの Visual Studio が起動する。
プロジェクトの操作履歴データは除いてあるため、その影響で最初は起動に少し時間がかかる。
Windows 11 の場合だと、ダウンロードしてきたプロジェクトデータの場合は Visual Studio の方でこのように
注意が表示されるようになっているようである。
当プロジェクトデータは最新情報のウイルスチェック済で、ソースコードも見てもらえば解ると思うが、怪しげな仕込みなども一切していないため 信頼して続行 で進んでもらえばよい。
操作履歴データは除去してあるため、最初の読み込みだと少し時間が掛かる。
操作履歴データがないため、表示も展開も何もされていないこのような状態での起動となる。
右側がソリューションエクスプローラーのタブになっていることを確認しながら
各赤丸でこのように展開しておき、メインである WindowOrigin.cpp をダブルクリックで、左編集側に表示させる。
この WindowOrigin を F5 キーでデバッグモード実行してみると
このように、アイコン情報を除く内部リソースとＭＦＣ関連を削除したさらに何もないウインドウがただ表示されるだけのものが、当ブログにおける出発点の今回の WindowOrigin となる。
新規プロジェクトの［ Windows デスクトップ アプリケーション ］での見本だと、アイコンファイル名もプロジェクト名と同じに、ソースファイルと同じ場所に梱包されている状態から始まるが、どの部分をどう変えればいいのかを解りやすくするために WindowOrigin では ImagePNG.ico という名称にして
このようなテキトー見本に差し替えている。
ここから以下、内部リソースとＭＦＣ都合の削減後である WindowOrigin の説明をしていくが、なぜそうしたのかの当ブログとしての意図や経緯をざっと伝えておいた上でないと、当然理解できる訳もないため、だから上述してきた。
Microsoft の見本（ WinProgTest との比較で ）からの、まずは手続き（ 関数。プロシージャ ）側の変更としては、ウインドウ生成をしているだけの InitInstance を削除してその部分を wWinMain に移動したのと、ＭＦＣダイアログ画面用のウインドウハンドル＆メッセージ処理用 About は当ブログでは使わないため削減した（ 手続きが５個だったのを３個にした ）くらいになる。
後は、内部リソースからの参照処理を消しただけだが、
見方では、プロジェクト名、ウインドウ名、登録名の文字列が設置してある内部リソース側から取得するという、その処理の部分を撤廃して文字列を直接書き込むようにしたのが、１と２の赤枠の部分になる。
３の赤枠の部分は、これは当ブログ筆者の書式基準として、手続きの引数指定内や、Ｃステート内（ if や while など ）の中に手続きを記述して引数を渡す、という従来の書式は、その手続きを作った訳ではない人が見たら見やすい訳がない上に、機械語上でも処理が簡略化される訳でもなんでもない。
書式に関しては次章以降も説明していくが、例えば sizeof や GetLeft といったかなり単純なものでなければ、当ブログでは基本的に避けることにしている。
次は MyRegisterClass だが
５の赤枠は、メニュー群（ 内部リソース情報 ）は使用しないため NULL（ 0 でも可 ）を、４と６の赤枠はアイコン情報を exe 内に内在させるために残してある。
状況を解りやすくするために、MyRegisterClass の引数を変更している。
少し注意点として、Windows でのアイコンに関するリソースの仕様は、LoadIcon を使って内部リソースを読み込むという、この手法外のことをすると、つまり LoadIcon の実態である LoadImageW でのアイコン情報用のパラーメータ外のものにすると（ アイコンの場合はつまり内部リソース情報を介すパラメータを守らないと ）、Windows 側がその exe のアイコン情報を正確に認識できなくなる問題が発生する。
リソース情報を介さずにアイコン情報を設定してしまう場合、exe ファイルに ico ファイルも同フォルダに同行させてやらないと、その exe が置かれたフォルダごとでアイコンが正常に表示されなくなり、その欠陥を Windows 側が、その exe が置かれているフォルダごとでおかしな認識をし続けてしまう（ 内部リソースの内、アイコン情報は Windows 側のフォルダ管理リソースと連動している ）という少し厄介な症状が起きる、そのため当ブログでは内部リソースの内、アイコン情報のみはやむなく残すことにした。
ここでは wcex.hIcon と wcex.hIconSm とアイコン情報がふたつあるが、
この画面は Windows 10 での、タスクバーを右縦で使用している画面だが、ウインドウ側に表示されているアイコンが wcex.hIcon で、タスクバー側に表示されているアイコンが wcex.hIconSm、WindowOrigin では両方とも同じにしている。
wcex.hIcon には内部リソース情報を正確に渡し、情報の内容が同じだからと wcex.hIconSm の方には例えば LoadIcon を使わずに
wcex.hIconSm = wcex.hIcon;
という渡し方をしても、正常に動作しないことも確認済みのため、両方とも LoadIcon を使って内部リソースからアイコン情報を登録してやらなければならない、この仕様は Microsoft / Windows の仕様がかなり濃い部分のため、当ブログもここだけ沿うことにした。
次に、WndProc だが
Microsoft 見本から処理自体は変えていないが、当ブログ筆者は switch case は基本的に使わないため、全て if に変更している。
cpp の説明はここまでで、内部リソース側の変更点に触れるが、まず、右側のソリューションエクスプローラーの
Resource.h ファイルをダブルクリックして左編集表示させると、ここは見本側（ WinProgTest ）の方では
と色々羅列されているが、当 WindowOrigin の方では
アイコン識別用のための項目ひとつのみにしている。
内部リソースファイルの rc の方は
ソリューションエクスプローラーの rc ファイルで右クリックポップメニュー コード表示 で、ここも Microsoft の見本（ WinProgText ）では
このように見本の方ではＭＦＣの都合等があれこれと続いて書かれているが、WindowsOrigin の rc ファイルでは
アイコン情報のためだけのこの１項目のみにして、後は全て削除している。
Resource.h と プロジェクト名.rc のこのふたつは、Ｃ／Ｃ＋＋とは完全に別の Microsoft 独自のマクロ書式規律の仕様になっていて、リソース関係の設置・設定はこの中で完結させなければならないようになっている。
変数名の定義や、#define での定数名を定義する際、IDI_ や IDD_ や IDC_ といった、２文字目までが ID で、４文字目がアンダーバーになっている名称は Microsoft のマクロだと認識するための予約語扱いになっていて、マクロ外でもエラーになるため、そこだけ注意になる。
当ブログ説明では、内部リソースについてはこれを初期状態に、基本的にはここから触れることはしない。
ちなみに、見本リソース内在の WinProgTest と、その大部分を削除した今回の WindowOrigin の、双方の exe では
WinProgTest.exe では 104 KB、一方でアイコン情報のみ内在させ他は全て削減した WindowOrigin.exe では 13 KB と、だいぶ少なくなっていることが確認できる。
今回は最後に、例えば今回のこの WindowOrigin をプロジェクトの初期状態にしたい、といった想定についての、そのファイル操作についても、この WindowOrigin の場合で一応説明しておきたい。
Visual Studio Community 2026 からの、新しいプロジェクトの作成で［ Windows デスクトップ アプリケーション ］を選んで、プロジェクト名を
例えば、ScreenProg という名称で（ ここでは C:\FilesVC\ というフォルダで ）作成したとする。
［ Windows デスクトップ アプリケーション ］でプロジェクトを作ったことがある場合は、２回目以降はすぐにこのような画面になると思うが、プロジェクトが作成されたらこの ScreenProg プロジェクトの Visual Studio をいったん終了する。
エクスプローラで、ScreenProg プロジェクトフォルダの、ソースファイルのあるフォルダ（ ScreenProg の中の ScreenProg ）に入っている
Resource.h ScreenProg.cpp ScreenProg.rc の３ファイルを削除する。
次に、WindowOrigin のソースファイルフォルダから
ImagePNG.ico Resource.h WindowOrigin.cpp WindowOrigin.rc の４ファイルを、ScreenProg 側のソースファイルフォルダにコピーする。
ScreenProg 側のソースファイルフォルダで、WindowOrigin.cpp と WindowOrigin.rc のままになっているこのふたつを、このプロジェクト名つまり ScreenProg にリネームする。
これでファイルの差し替えが完了のため、
プロジェクトファイルがあるフォルダの slnx ファイルから、ScreenProg のプロジェクトの Visual Studio を起動し、ソリューションエクスプローラーから ScreenProg.cpp をダブルクリックして編集表示させる。
赤枠の１、２、４をそれぞれ ScreenProg に変更、３は大文字 SCREENPROG に変更。
Ctrl + S で保存。差し替えができていることを F5 キーで確認できる。
Visual Studio にはこのように、自身で作ったプロジェクトを元手に自動的に名称変更の新プロジェクトを作る、という機能が特にないため、そうしたい場合はこのように手作業でやるしかないが、手間ではあるが意味が解っていれば大して難しくない。
今回は、当ブログではこの WindowOrigin を初期状態としているという、その事情や経緯を伝えるための説明になる。
次章では、内部リソースおよびＭＦＣを使わずに画面構成をしていく場合はどうなるのかについて、Ｃと Windows 標準 API 中心で紹介していきたい。