Win32API質問箱 Build127

**デフォルトの名無しさん** · 2021/12/09(木) 21:32:56.60

Win32APIについての質問はこちらへどうぞ。

■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。
　英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで

■過去スレ
Win32API質問箱 Build126
https://mevius.5ch.net/test/read.cgi/tech/1588339011/
Win32API質問箱 Build125
https://mevius.5ch.net/test/read.cgi/tech/1551247748/
Win32API質問箱 Build124
https://mevius.5ch.net/test/read.cgi/tech/1510395780/

■関連スレ
Visual Studio 2020 Part1 https://mevius.5ch.net/test/read.cgi/tech/1634166667/
Visual Studio 2019 Part7 https://mevius.5ch.net/test/read.cgi/tech/1634178709/
Visual Studio 2017 Part7 https://mevius.5ch.net/test/read.cgi/tech/1558179898/
【C++】 DirectX初心者質問ｽﾚ Part41 【C】 https://mevius.5ch.net/test/read.cgi/tech/1521786252/

**デフォルトの名無しさん** · 2023/03/04(土) 01:56:42.82

MFCの設計が変なのは出てきた時期も悪かったと思うね
まだVC++含めて各C++コンパイラでtemplateもまともに動かない＆互換性に問題があるような状態だったし

**デフォルトの名無しさん** · 2023/03/04(土) 04:09:52.49

MFCは最初から死産だったがMS製だからVisualStudioに標準で入ってるからと使わざるを得なかっただけ
設計思想はDelphi(C++Builder)よりも数段劣ってる
当時のC++がうんこすぎたのもあるがこれは処理系の設計者のセンスの問題だろう

**デフォルトの名無しさん** · 2023/03/04(土) 06:03:41.66

>>490
その頃のBorlandはOWLだぞ

**デフォルトの名無しさん** · 2023/03/04(土) 10:32:23.94

MFCはDocument-Viewアーキテクチャがわかりにくいとかそのパターンに合わないアプリが
作りにくいとかはあったけど、それ以外は当時のC++でよくやったと思うよ。

**デフォルトの名無しさん** · 2023/03/04(土) 10:38:13.23

C++じゃなくてCからでもGDI+は使える
面倒だから避けるけど

**デフォルトの名無しさん** · 2023/03/04(土) 10:40:00.46

>>490
Frameworkの出来としてはBorlandの方が完全勝利だったが
マーケティングで負けたな

**デフォルトの名無しさん** · 2023/03/04(土) 10:41:24.02

>>491
いやいやMFCの設計者が馬鹿過ぎただけ

**デフォルトの名無しさん** · 2023/03/04(土) 10:43:16.79

>>492-493
ほんそれ

**デフォルトの名無しさん** · 2023/03/04(土) 10:45:47.20

>>494
どうみても糞は糞

**デフォルトの名無しさん** · 2023/03/04(土) 10:51:57.61

Document Viewが分かりにくいとか
そんなんで音を上げるやつがセンスとはよく言うよ

**デフォルトの名無しさん** · 2023/03/04(土) 11:11:54.38

MFCなんてクソ過ぎて当時でも使ってなかったよｗ

**デフォルトの名無しさん** · 2023/03/04(土) 11:18:57.88

MFCよりSDKというのは当時の合言葉だったろ

**デフォルトの名無しさん** · 2023/03/04(土) 11:21:50.94

Smalltalkの下手な真似は目が点になったけどね

**デフォルトの名無しさん** · 2023/03/06(月) 08:40:31.04

使わざるを得なかっただけてｗ
使うも使わないも使用者の自由だろｗ

**デフォルトの名無しさん** · 2023/03/06(月) 09:09:43.33

MFC ATL WTL
用途によって使い分け
ひとつのクラスライブラリに固執する必要性も必然性もない

**デフォルトの名無しさん** · 2023/03/06(月) 14:14:58.36

Smalltalkの真似はObjective-C

**デフォルトの名無しさん** · 2023/03/06(月) 14:55:30.78

>>504
途中から参加した案件では選択権がない

**デフォルトの名無しさん** · 2023/03/07(火) 08:46:10.01

それは途中参加した案件が使ってるから使わざるを得ないだけで
VSに入ってるから使わざるを得ないわけではないね

**デフォルトの名無しさん** · 2023/03/07(火) 12:07:50.78

言うまでも無く地雷案件
参加する前に嗅覚で判断して離脱

**デフォルトの名無しさん** · 2023/03/07(火) 13:22:26.79

上から降ってくる仕事を、雇われの立場の者は断れない

**デフォルトの名無しさん** · 2023/03/07(火) 17:55:18.76

信仰を理由にすればなんでも断れる

**デフォルトの名無しさん** · 2023/03/08(水) 06:45:47.34

退職して出家でもすんのか
頼むから犯罪に加担するのはやめろ

**デフォルトの名無しさん** · 2023/03/09(木) 00:18:42.41

Win32というかVC++だけど_itow_s系列って何文字書き込まれたかを返してくれるバージョンなんてないよね？
ChatGPTに聞いたら最後にint*で返してくれるオーバーロードがあるって言ってたんだが

**デフォルトの名無しさん** · 2023/03/09(木) 04:47:01.50

意味の分からない現象に遭遇したので質問させてくれ。
ここが適切かどうか微妙だけれど、もしスレが違っていたら案内いただけるとありがたい。

さて、VC6時代に作成され、プロジェクトを随時新しいVSに移行して開発しているアプリがある。
特にフレームワークは使用しておらずwin32Apiで書かれている。リソースエディタは、VS付属のリソースエディタだ。

windows10/VS2019までは問題なかったんだが、windows11/VS2022でビルドしたとたん、ダイアログのサイズが横に６ピクセル縦に２ピクセル小さくなって、中身の右と下が詰まる現象が発生した。
同じプロジェクトに新規にダイアログを加えても同じだった。
なお、この現象は、タイトルバーを追加したときだけ起こる模様。また、フォントの指定をしてもしなくても同様だ。

当たり前だが、新規にテストプロジェクトをwindows11/VS2022で作成した場合は起こらない。

なお、windwos10でビルドしたものを windows11で実行すると正しく表示される。
また、windows11でビルドしたものを windows11 で実行した場合は上記のようになるが、windows10で実行すると正しく表示される。
windwos11の互換モードをチェックすると、少しだけ改善される（詰まりがわずかに改善する）
user32.dll関連で何かあるのかな？　正直訳が分からないよ。

識者の意見を求む。

**デフォルトの名無しさん** · 2023/03/09(木) 14:01:14.32

AdjustWindowRect
AdjustWindowRectEx

**デフォルトの名無しさん** · 2023/03/09(木) 15:07:30.71

windows10/VS2019　で新規作成し
　同環境でビルドしたものを windows11 で実行
　windows11　でビルドしたものを windows11 で実行
で差があるんかな？

_WIN32_WINNT
_WIN32_IE
WINVER
あたりの値を固定化しているのかどうか

**514** · 2023/03/09(木) 15:19:13.60

>515
え、rcファイルで定義されたダイアログを、DialogBoxParam()などで表示したらそうなって困っているという話なのですが。
もしかして、windows11の時だけ、横に６ピクセル縦に２ピクセル広げるという力業でやれということですか？ｗ

**514** · 2023/03/09(木) 15:22:59.99

>516
プロジェクトを作成したのはVC6のようです。
以降ずっと継承しているらしく、そのプロジェクトをwindows10/2019でビルドすると問題が起きないのですが、
windows11/2022でビルドすると、実行環境がwindows11に限り現象が発生します。謎です。
バージョンは定義されています。この辺りを最新の0X0Aあたりに設定してリトライしてみます。
THX。

**デフォルトの名無しさん** · 2023/03/09(木) 15:36:17.03

Windows11/2019でビルドしたらどうなんじゃろ

**デフォルトの名無しさん** · 2023/03/09(木) 16:10:10.53

ビルドしたOSのバージョンに合わせてウインドウスタイルを調整する部分があるのでは？
VS2019とVS2022の違いで言うと、ヘッダーでの #ifdef の分岐条件の違いでしょ？

windwos10でビルドしたものを windows11で実行すると正しく表示される。
　→OSがWindows10アプリとして実行しているからオプション未指定でも正常

windows11でビルドしたものを windows11 で実行した場合は上記のようになる
　→OS的にはwindwos11アプリだけどビルドとしてはWindows10アプリ、その齟齬で表示が崩れる

が、windows10で実行すると正しく表示される。
　→OS的にもビルド的にもWindows10アプリとして実行しているから問題ない

windwos11の互換モードをチェックすると、少しだけ改善される（詰まりがわずかに改善する）
　→疑似的にWindows10アプリとして実行するが、部分的に完全な互換が出来ないでいる

と言う妄想をしてみた

**デフォルトの名無しさん** · 2023/03/09(木) 17:01:34.32

>>520
その #ifdef の分岐条件になりえるのが
_WIN32_WINNT WINVER と _WIN32_IE

**デフォルトの名無しさん** · 2023/03/09(木) 17:11:02.85

>>521
そうだけど「あたりの値を固定化しているのかどうか」って書かれているから
それは「本来条件式に任せるべきところを直書きしているのでは？」と言っているのかと受け取ったけど

逆に俺は条件式に任せているから古い開発環境でうまく行ってないだけでは？と思ってるって話ね
だから自分で条件分岐を追加するか、本人が>>517で言うように力技でねじ伏せるかしかないのでは？ってこと

**デフォルトの名無しさん** · 2023/03/09(木) 17:11:56.14

おっけー了解

**デフォルトの名無しさん** · 2023/03/09(木) 17:13:51.29

動作環境を固定化するのに
#ifdef _WIN32_WINNT
#undef _WIN32_WINNT
#define _WIN32_WINNT 0x○○○
#endif
というのは、俺はやってる　これの宣言の後に windows.h 等を読むように
って制限かかるけどね

**デフォルトの名無しさん** · 2023/03/10(金) 08:43:31.77

とりあえず関連するライブラリのビルドを込みで、すべてWINVERと_WIN32_WINNTの定義を0x0A00にしてやってみたが結果は変わらず。

>520
問題は、「どこで」そのOSのアプリだと認識しているのかという点ですね。
urn:schemas-microsoft-com:compatibility.v1 で、マニフェストに定義する値って、windows10も11も同じですし。
Common-Controlsの時みたいに、windows11スタイルを禁止するのになにか定義する値でも……と思ったけどみあたりませんし。

>522
とりあえずOSのバージョンを取得しているところをgrepして追いかけてみたが、そういうのはなさそう。
そもそもダイアログリソースからの作成ですしね。

問題が再現する最小のビルドを作成してるのだけれど、これがまあ大変（普通に10/2019で新規作成すると問題が起こらない）なので
問題が起こるプロジェクトを複製して、とりあえず WinMainがあるソース以外を全部削除してから順に試してみます。
泣けるぜ。

締め切りに間に合いそうになかったら、とりあえず超力ワザで。
こうやってクソソースができていくんだなぁ……

**デフォルトの名無しさん** · 2023/03/10(金) 09:09:30.83

Win10/2022でビルドしてみたりWin11/2019でビルドしてみたりはしたんかいな

**デフォルトの名無しさん** · 2023/03/10(金) 12:17:19.97

ここまでDwm略のAPIの話が一切出てなくて草

**デフォルトの名無しさん** · 2023/03/10(金) 12:34:03.89

ものすごい大変だったけど、最小化コードを作ったら原因が判明したので報告しておく。

おそらく windows2000 の頃まで遡る話だけれど、
ダイアログをセンタリングするためのクラスメソッド内で、ダイアログをセンタリングするためにSetWindowPos()じゃなくて、MoveWindow()が使われていたのが原因だった。
なんとエアロが有効な状態で、455 x 179 のダイアログを、MoveWindow()を使って、MoveWindow(100, 100, 455, 179) へと動かすと、サイズが、441 x 172 になる！
そういうもんなのかー。こんなの知らないとわかんないよ……

**514** · 2023/03/10(金) 12:36:58.25

sage忘れすまん。
てか、これ客観的に見てバグとしか思えない挙動だ。
とりあえず解決ということで。ありがとうございました。

**514** · 2023/03/10(金) 13:06:28.99

連投すまん。
確認したところ、windows11/2022で新規作成したプロジェクトでも再現します。
windows11だけなので、11でUIを一新した際に発生した、MoveWindowのバグってことで納得します。
これが仕様だとしたら、ちょっと首をひねらざるを得ないですね。

**デフォルトの名無しさん** · 2023/03/10(金) 13:20:48.59

納得しますじゃなくバグみつけたなら報告しろよ

**デフォルトの名無しさん** · 2023/03/10(金) 15:04:54.29

>>531
ここで報告されたやん
俺らMS本社のエリートなんだから頑張ってfixしようぜ

**デフォルトの名無しさん** · 2023/03/10(金) 15:18:22.32

ここで報告できると本気で思ってるのか
おめでてーな

**デフォルトの名無しさん** · 2023/03/10(金) 16:23:50.60

どう対処していくかは悩ましいところだろうけど
さしあたり見つかってよかったね

**デフォルトの名無しさん** · 2023/03/10(金) 19:20:08.44

MoveWindowなんて基本的なAPIのバグを報告したら、幾らか貰えそうな気がする
ここ見た他の誰かが、もう報告してるかもねw

**デフォルトの名無しさん** · 2023/03/10(金) 19:29:59.85

それってバグなのか？
LunaやAeroの影響を受けるような前提があるんじゃないか？

**デフォルトの名無しさん** · 2023/03/10(金) 21:41:52.52

>>513
読み取った後に、wcslen() で文字数を数えると良い。

**デフォルトの名無しさん** · 2023/03/10(金) 21:52:37.44

>>513
結論から言うと「無い」ハズ。
また、最後の引数が int* 型のものは存在していないように見える。
引数の説明欄も、以下の用に4種類のみで、その中に、該当のものは存在していない。

*Parameters
-value
Number to be converted.
-buffer
Output buffer that holds the result of the conversion.
-size
Size of buffer in characters or wide characters.
-radix
The radix or numeric base to use to convert value, which must be in the range 2-36.

**デフォルトの名無しさん** · 2023/03/11(土) 17:44:54.81

ウインドウサイズの現象どこかで見たな
たしかリンカオプションの/subsystem:windows,X.YとManifestFileの組み合わせで
APIの挙動が変わるんじゃなかったかな

**デフォルトの名無しさん** · 2023/03/12(日) 18:57:18.20

>>537>>538
ありがとう、やっぱりないか
ChatGPTって結構間違った答え出してくるな

**デフォルトの名無しさん** · 2023/03/12(日) 22:11:40.77

自分では調べずにAIに聞いて、その確認も掲示板で他人に聞くスタイル

**デフォルトの名無しさん** · 2023/03/13(月) 07:50:35.89

ChatGPTを何だと思ってるのかｗ

**デフォルトの名無しさん** · 2023/03/13(月) 09:19:48.62

ChatGPTもBingも知らないことを知らないと言わずしれっと嘘ついてくるし回答が人の目に触れてなくて識者からのコメントもないからこれを信用するやつは頭湧いてる
Qiitaの方がまだマシレベルでこれに比べるとウィキペディアは神レベル
しかしそのどれも公式ドキュメントとは比べ物にならない糞

**デフォルトの名無しさん** · 2023/03/13(月) 11:17:06.85

答えの無い物を探すのが圧倒的に苦手
今までの「自称AI」と何ら変わらん野田

**デフォルトの名無しさん** · 2023/03/13(月) 12:16:45.84

道具に振り回される人って…ｗ

**デフォルトの名無しさん** · 2023/03/13(月) 14:09:26.73

他のプログラミングを出来るとされるAIでも、小学生でも習う円筒の体積すら、
半径の二乗を直径の二乗に間違えた間違いのコードを答えてきた。

**デフォルトの名無しさん** · 2023/03/13(月) 14:38:05.49

今のところは汎用対話AIだからね
対話力に重きを置いてる上に汎用型なので正確性に関してはかなり犠牲にされてる
結局人間もそうだけど専門型が出てきてこそだな
AIアート分野はローカルで各々が専門的に学習させられるからその辺一歩リードしてる

**デフォルトの名無しさん** · 2023/03/13(月) 15:38:27.48

>>546
どのAIにどう質問したの？

**デフォルトの名無しさん** · 2023/03/14(火) 12:02:53.79

プロセス間で同じファイルを読んだり書いたりしたいのですが、
一方が開いているときにはオープンに失敗させるのではなく、排他制御で待つようにしたいです。
Linuxとかだとflockという関数があるようですが、
Windowsで同じことをやるにはどういう方法になるのでしょうか？
ミューテックスを使うとなると、事前にミューテックスの名前も決める必要が出てくるのですが。

**デフォルトの名無しさん** · 2023/03/14(火) 14:53:13.19

>>549
https://learn.microsoft.com/ja-jp/windows/win32/api/fileapi/nf-fileapi-lockfileex

**デフォルトの名無しさん** · 2023/03/14(火) 15:49:06.52

>>550
これって、書き込むときはファイルのサイズは事前にはわからないのですが、
計算してからでないとロックはできないということなのでしょうか。
ファイルの任意の領域というよりは、ファイルそのものをロックしたいのですけど。

**デフォルトの名無しさん** · 2023/03/14(火) 15:55:53.14

＞ミューテックスを使うとなると、事前にミューテックスの名前も決める必要が出てくるのですが。

別にそんな必要はないでしょ
ユニーク名＋ファイル名でミューテックスを使えばいい
（※ユニーク名ってのは自分しか使わない名前のことね、例えばGUIDとかだけどそこまでがっちりやる必要もないとは思う）

**デフォルトの名無しさん** · 2023/03/14(火) 16:03:43.56

>>551
指定できる最大値を設定しておけばいい

＞ファイルの現在の終了位置を超える領域をロックすることは、エラーではありません。
とあるから事実上ファイルそのものをロックしたのと同じ

**デフォルトの名無しさん** · 2023/03/14(火) 16:27:54.12

>プロセス間で同じファイルを読んだり書いたりしたい
問題を無闇に複雑にしてると思わないか

**蟻人間** ◆T6xkBnTXz7B0 · 2023/03/14(火) 17:01:38.94

クライアント・サーバーモデルで、
サーバーだけが書き込めるとか言った制約があった方が良いかも知れません。

**549** · 2023/03/14(火) 18:23:18.32

アドバイスありがとうございます。
あるアプリから別のアプリを起動する際、
コマンドラインでは収まらないような長い情報を渡す必要があり、
ファイルに必要な情報を書いてやりとりするようにしています。
(コマンドラインにはそのファイルのパス名を渡している)

なので、ファイルを作成するアプリと、そのファイルを読み込むアプリがあり、
多重起動などのタイミングによってはアクセスがぶつかる可能性があるので、
このファイルに対する同時アクセスを制御したいという質問でした。
ミューテックスとLockFileExとどちらで実装するか、検討させていただきます。

**デフォルトの名無しさん** · 2023/03/14(火) 18:25:17.73

>>554
コンパイラとリンカで同じファイルを読んだり書いたりするのも
問題を無闇に複雑にしているのか？

**デフォルトの名無しさん** · 2023/03/14(火) 19:27:43.09

>>556
パイプを使えばええんちゃうかな？

**デフォルトの名無しさん** · 2023/03/14(火) 19:36:39.98

>>556
それはやり方が違うだろ
GetTempFileNameとか使って一時ファイルを作成すればすむ話

**デフォルトの名無しさん** · 2023/03/14(火) 19:54:35.88

>>559
それもやってみたのですが、多重起動などのタイミングによっては、
どうやっても、読み込まれずに放置されるゴミファイルができてしまいます。
テンポラリフォルダなんて気にしなければよいといえばよいのですが。

**デフォルトの名無しさん** · 2023/03/14(火) 21:32:45.60

Tempなんか使わずとも末尾PIDの名前でファイルなりを作れば重複起動その時においては名前は被らないし
引数の受け渡しとか程度の話ならオープン失敗したら数秒待って開き直せばいつか開けるだろ
書いてる間はどうせ読めても無意味なんだし

**デフォルトの名無しさん** · 2023/03/14(火) 22:38:01.69

WM_COPYDATAとかメモリマップドファイルとか

**デフォルトの名無しさん** · 2023/03/14(火) 23:24:45.28

>>556
>>558と被るけど名前付きパイプがお勧め。

**デフォルトの名無しさん** · 2023/03/15(水) 00:41:23.71

>>560
いや、ゴミファイルが出来る事があり得ないけどね…
その多重起動というのがどういうものか知らんけど、GetTempFileNameで上手く行かないのは、プログラムが悪いと断言できる
ま、これで駄目なら何やっても上手く行かないだろうね

**デフォルトの名無しさん** · 2023/03/15(水) 00:54:04.79

>>548
twitterで流行ってたものを誰かが試した結果を見て気付いた。

**デフォルトの名無しさん** · 2023/03/15(水) 01:02:47.82

>>565
それで遊んでみようと思ったのだけど何を使用していたのかわからないなら遊べないな残念

**デフォルトの名無しさん** · 2023/03/23(木) 01:09:16.30

>>490
正確にはMFCはMS-DOSの開発ライブラリ

だからGUIのWindowsとうまく噛み合わなかった

**デフォルトの名無しさん** · 2023/03/23(木) 06:12:16.80

Ruby では普通、外部コマンド・子プロセスの終了を待つから、実行順序は書いた順。
Process.#wait

一方、Kernel.#spawn は、終了を待たない。起動しっ放し

IO にはパイプ、ブロッキング/ノンブロッキング、同期/非同期もある

**デフォルトの名無しさん** · 2023/03/23(木) 07:28:24.76

>>567
うそおっしゃい

**デフォルトの名無しさん** · 2023/03/23(木) 08:33:51.91

>>567
コマンドベースの開発ライブラリならSDKだろ
MFCはGUIが前提のクラスライブラリとアプリケーション構築のプラットフォームをセットにしてWin32APIをラップしたもの

**デフォルトの名無しさん** · 2023/03/23(木) 11:05:08.93

>>567
これはひどい

そんなの関係ねぇ
GUIのWindowsとうまく噛み合わなかったのは
MSVCの開発陣がC++への理解が足りなかったから

**デフォルトの名無しさん** · 2023/03/23(木) 11:15:29.65

>>567
お前MFC知らんだろ

**デフォルトの名無しさん** · 2023/03/23(木) 23:45:58.18

久々に清々しい嘘を見た

**デフォルトの名無しさん** · 2023/03/24(金) 01:24:11.23

インストーラーの無い野良EXEのAUMID(Application User Model ID)をOSに登録する方法教えてください

**デフォルトの名無しさん** · 2023/04/03(月) 14:17:49.75

>>570
Microsoft Cがいつからあるのか知らないのか。

MFCにはGUI限定などという定義はない。

そもそもMFCはCUIのライブラリから始まっている。

**デフォルトの名無しさん** · 2023/04/03(月) 14:20:45.40

>>570
SDKの意味すらわかってねえのか？

あんたのいうMFCは、Windows SDKが扱うWin32APIをさらにラッピングしたMFCのことだ。

あんたの言っていることは滅茶苦茶だ。

**デフォルトの名無しさん** · 2023/04/03(月) 14:34:38.52

>>571
どうでもいいけど、マイクロソフト内でC言語とC++の混在そのものに悩んでいたのも知らないようだな

マイクロソフトはC言語派、C++派、Windowsを普及させるためにVB流用派と、試行錯誤を繰り返していた時代にMFCが誕生したと思っているなら、時期がずれていてリアルタイムでは知らなかったと言っているようなもの

**デフォルトの名無しさん** · 2023/04/03(月) 15:01:56.44

MS-DOS の頃ってMSのコンパイラは統合環境だった？
C++ どころか Cコンパイラでコマンドライン上から nmake 叩いてわ

**デフォルトの名無しさん** · 2023/04/03(月) 15:07:52.75

B:\>msc hello.c

**デフォルトの名無しさん** · 2023/04/03(月) 15:10:57.50

ウィキペディアの説明が、Microsoft C 7.0以前の話がないせいで、Microsoft CとVisual C++の区別がついていないのね。

Windows 95、98の時代は、MS-DOS 6.2とWindows 95・98(内部MS-DOS 7.0・7.1)の併存期間で、MFCはMS-DOS 6.2をターゲットとしたものと、Windows 95をターゲットとしたものがある。

まず俗称「MSVC」と呼ばれるものは、Windows 95アプリケーションの開発を意識したもので、マイクロソフト「VC」と言っているあたりからわかるようにC言語でのWindows 95アプリケーションの開発を主としている。

ここでC言語からC++の移行をマイクロソフトはやろうとして、Windows APIがオブジェクト指向ではないところで無理が生じた。

そこでMFCを大幅に強化することでC++でのアプリケーション開発をしてもらおうとしたが、すでにWindows SDKの開発の知識がある開発者は、Windows SDKでのCでもC++よいというのに慣れていて、MFCを使えというのは、それまでの知識と違っており、無駄なクラスライブラリとしか思えなかった。

MFCはWindows 3.1でも影が薄い。マルチタスクではないと言えてしまうWindowsでは、MFCのメリットなどなく、無駄にサイズが大きくて重いコードが作られるため、性能、スペックの低いパソコンではMFCを使う理由がなかった。

MFCはGUIだけで使われるものではないため、CUI環境の開発でも使われている。

MFCどころかWindows 32APIでも、画面がある前提になっているコードを書かないといけないが、実際には画面がないものを作るのにも使われる。

MFC、Visual C++、Windows SDKの話がごっちゃになって、MFCを使うにはVisual C++でMFCを利用して、MFCがWindows SDKとセットだと認識できない点は理解できる。

まあ、ウィキペディアの記事は、根拠不明の創作が多いとわかってないとだまされるよな。

**デフォルトの名無しさん** · 2023/04/03(月) 15:18:50.66

Win32がオブジェクト指向ではないって？
ハンドルを使う関数（つまり大半）はオブジェクト指向だと思うが

もしかしてオブジェクト指向とはC++やSmalltalkを使うことだと思ってるのか？

**デフォルトの名無しさん** · 2023/04/03(月) 15:19:55.66

>>578
統合開発環境と何の関係があるのか？

Windows 95アプリケーションでも、統合開発環境は必須ではない。

画面のデザインのときだけ利用するという使い方が多かった。

Direct Xが普通に使われるようになってからは、統合開発環境は画面ごと吹っ飛ぶので、統合開発環境そのものも動かないこともあるし、統合開発環境を自分が作ったもので壊すことがあるから、Windows 95、98系では、Visual製品に期待しても、Visual統合開発環境とWindows OSのポンコツコンボは、いま思っているより意味をなしていなかったんだよ。

**デフォルトの名無しさん** · 2023/04/03(月) 15:25:54.31

>>582
MFC=マクロ出力とセットになった統合環境前提って印象だったものでね
リソース周辺のアレ

**デフォルトの名無しさん** · 2023/04/03(月) 15:26:39.12

>>581
そこで使われるオブジェクトとオブジェクト指向とは関係ない
アセンブラのオブジェクトファイルと同様だ

**デフォルトの名無しさん** · 2023/04/03(月) 15:28:25.60

>>581
オブジェクト指向設計ではなかったんだよ。

C言語とC++は書き方が少し異なるだけだったので、Windows SDKではC++で書くとオブジェクト指向っぽくなり、C言語で書くとこれでいいのかという書き方で、Windows 95のアプリケーションが作れた。

ここはWindows SDKがオブジェクト指向ではないという理由がある。

APIそのものはオブジェクト指向ではなかったので、オブジェクト指向にするにはMFCを挟むという変なことをすることをしていた人間もいる。

たった数年で変わった話なので、過渡期を知らないと誤解が生じるのはわかる。　

**デフォルトの名無しさん** · 2023/04/03(月) 15:37:01.22

>>584
GetObject()なんか多相そのものやん

**デフォルトの名無しさん** · 2023/04/03(月) 15:39:17.90

すまん関数名間違えた
SelectObject()だ

GetObject()はオブジェクト指向と手続き型の切り替えだね

**デフォルトの名無しさん** · 2023/04/03(月) 15:56:54.48

Win32APIの基本構造そのものがイベントドリブンのメッセージ駆動なのでオブジェクト指向を土台にしている
Windowsのマルチタスクはオブジェクト指向で成り立っているだろ

**デフォルトの名無しさん** · 2023/04/03(月) 16:40:18.30

そうそう
ウインドウプロシージャのcaseなんか典型的だな

**デフォルトの名無しさん** · 2023/04/03(月) 16:48:57.33

>>575
>そもそもMFCはCUIのライブラリから始まっている。

doubt