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/

**デフォルトの名無しさん** · 2022/12/08(木) 05:02:17.43

>>432
あー確かに減算してますね。
気がつかなかった私がどうかしてました。
ご指摘ありがとうございます。

**デフォルトの名無しさん** · 2022/12/19(月) 11:12:22.75

ディスクへの書き込みを別の場所へ書き込むようにインターセプトすることってドライバじゃないと不可能？
ReadDirectoryChangesやFindFirstChangeNotificationって通知だけでディスク変更操作に手を加える事は出来ないよね
パスが常に一定の物であればジャンクションやシンボリックで対応可能なんだけど

**デフォルトの名無しさん** · 2022/12/25(日) 08:27:23.13

その程度の知識の素人が手を出せるレベルの処理じゃないだろ
仮想デバイスとかどうすんの

**デフォルトの名無しさん** · 2023/01/19(木) 12:53:53.04

古い32bitプログラムをVS(ツールセット2010)でx64でビルドしてるんですが
「外部シンボル "sprintf" は未解決です」などのリンクエラーが大量に出て困ってます。
「legacy_stdio_definitions.lib」を使えという情報もあったんですが
2010ベースだと恐らくない？為か見つからないと怒られます。
色々事情があって最新版には移行出来ません。64bit化は諦めるしかないでしょうか？

**436** · 2023/01/19(木) 14:01:27.21

>436
チマチマと自分で設定弄ったりしてたら解決出来そうでした。

**デフォルトの名無しさん** · 2023/01/20(金) 00:30:28.27

ちゃんと無いなら自分で作るのもあり

**デフォルトの名無しさん** · 2023/01/22(日) 10:35:53.94

Windows Explorerではファイルに由来する属性、例えば画像のサイズとか、
MP3のタイトル、プログラムの説明とか表示できるけど、
それを取得するAPIは用意されててつかえたりしますか？
それともあれはExplorerで頑張って色んなフォーマットに対応してるの？

**デフォルトの名無しさん** · 2023/01/22(日) 12:15:09.84

>>439
このあたり↓ではないか？

MP3ファイルからタイトルやアーティスト名などを取得するには？［C#、VB］ - ＠IT
https://atmarkit.itmedia.co.jp/fdotnet/dotnettips/591mp3tags/mp3tags.html

Shell Interface (Shell32) | Microsoft Learn
https://learn.microsoft.com/en-us/dotnet/api/shell32.shell

間違ってたらごめんね

**439** · 2023/01/22(日) 13:35:39.24

>>440 Shell32.dllのGetDetailsOfを使うのずばりでした。
ありがとう！自前で全部揃えるのは嫌だとおもってたから。

**デフォルトの名無しさん** · 2023/01/22(日) 18:45:34.11

>>440
2つ目のURLは違ったね。多分こっち↓だ

Shell object (Shldisp.h) - Win32 apps | Microsoft Learn
https://learn.microsoft.com/en-us/windows/win32/shell/shell

訂正します

**デフォルトの名無しさん** · 2023/01/27(金) 14:29:22.14

>436-437
もう解決したみたいだけど
文字通り legacy_stdio_definitions.lib をリンクすれば良い
あるいは sprintf をやめて安全な snprintf (それ以外の legacy があればそれらも) 等を使うコードに変更する

**デフォルトの名無しさん** · 2023/01/28(土) 15:17:14.74

俺もそろそろANSI32bitアプリをunicode64bitアプリに更改したいなあ
まあ64bitにする意味は全く無いんだけど
せめてunicode化して、流行りの顔文字ぐらい表示できるようにしたい
あれのレンダリングはどうやるんだろうね
TextOutみたいなレベルのAPIじゃ無理だよね？

**デフォルトの名無しさん** · 2023/01/28(土) 16:02:05.59

>>444
Direct2Dなので描画ハンドラ関数の丸ごと書き換えが必要

**デフォルトの名無しさん** · 2023/01/28(土) 22:31:52.79

正確にはDirect2D+DirectWriteだね

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

QueryPerformanceFrequencyで取得した値が10MHzになってるんですが
何時からこの値になったのか、時期と実装が変わった経緯分かる方いますか？？

**デフォルトの名無しさん** · 2023/02/01(水) 07:50:03.36

もともとハードウェア次第だし、実装を変えたというわけじゃないんじゃね？
https://ja.wikipedia.org/wiki/High_Precision_Event_Timer

**デフォルトの名無しさん** · 2023/02/06(月) 00:05:16.01

>>447
最近2台のPCで取得したら10MHzだった。第8世代か第9世代のCoreと第10世代のCore。
ぐぐったらもうちょっと小さい値が出てきた。

**デフォルトの名無しさん** · 2023/02/06(月) 00:41:55.57

>>447
Hyper-V上だと10MHzになる模様
https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps

**デフォルトの名無しさん** · 2023/02/12(日) 10:07:22.45

ResEditが無くなってしまったみたいだけど、何があったんや？
単に需要がなくなっただけ？

**デフォルトの名無しさん** · 2023/02/12(日) 11:39:51.87

統合環境と一体化した

**デフォルトの名無しさん** · 2023/02/13(月) 02:53:34.52

ウィンドウメッセージキューと socket を WaitForMultipleObjects みたいに同時に待ち受ける方法はある？
現状は通信処理は別スレッドでやってるけど、これを敢えて GetMessage のループでやりたい。
というのも、好奇心上の取り組みでメモリ使用量を極限まで減らしたくて、まずスレッドを減らしてみようと思って。

あとちょっと API の話からは逸れるんだけど、VisualStudio で C++ のデスクトップアプリの雛形をビルドしただけのものでもメモリをコミットサイズで 2MB とか食ってて、スレッドも 4つくらい動いてるんだけど、これって何？
起動してから少し放っておくとスレッドは 3つくらい終了するから、いらないものなら排除したい。
いろいろ削ぎ落とすリンカオプションの設定とかあったら教えてほしい。
スタックサイズやヒープサイズは数十KBに設定してみたけど、あんまり違いは見えない。

**デフォルトの名無しさん** · 2023/02/13(月) 03:36:15.30

>>453
MsgWaitForMultipleObjects　を使う

**453** · 2023/02/13(月) 13:19:42.95

>>454
それだ！
ありがとー

**デフォルトの名無しさん** · 2023/02/14(火) 08:25:48.17

ソケットなら WSAAsyncSelect でソケットのイベントを WindowMessage に連動させる案もある

**453** · 2023/02/14(火) 14:53:30.32

>>456
それの方が GetMessage のループに馴染みそう。
そっちも試してみるよ。ありがとー

**デフォルトの名無しさん** · 2023/02/15(水) 11:23:09.93

シンプルにやるならGetMessageじゃなくPeekMessageでノンブロックループして定点観測するという事も出来る

**デフォルトの名無しさん** · 2023/02/15(水) 12:21:16.78

>>458
そのループがノーウェイトのビジーループになっちゃうじゃん
やることあるときだけ GetMessage が返ってくれるんだから、そっちのがシンプルでしょ。

**デフォルトの名無しさん** · 2023/02/15(水) 13:10:37.60

ところで、メッセージループで GetMessage したメッセージを DispatchMessage せずに、そのループ内で処理しちゃってもいい？
ウィンドウプロシージャに書いてる switch やら DefWindowProc をループ内に直接書いちゃうの。

**デフォルトの名無しさん** · 2023/02/15(水) 13:33:51.32

>>459
いや何も処理する事がなければSleep(1)でも挟むのが常套手段
GetMessageの内部だってそうなってるはず
GetMessageの場合はカーネル空間でループ回してるだろうからPeekMessageループよりIO回数が減ってパフォーマンス上は有利だろうが

**デフォルトの名無しさん** · 2023/02/15(水) 13:43:45.82

>> 460
ダメです
DispatchMessageは自プロセスに飛んできたOSとか他プロセスのメッセージも振り分ける

>> 461
待つならSleep(1)よりもWaitForSingleObjectのほうが軽い

**デフォルトの名無しさん** · 2023/02/15(水) 13:48:07.11

>>461
常套手段ってw
そしたら到着したメッセージを即座に処理できないでしょうよ。
イベントを待つというのは待ちながらもシグナル時は即座に反応できるというのが最大の利点なのに、わざわざそれを殺してどうするの。
そしてカーネル空間でも GetMessage は sleep しながらのループでなんか回してないと思うよ。
アプリケーションが何かを待ってる時には、スケジューラがそのアプリの実行を止めてしまう(タイムスライスをあげない)。
GetMessage で言えば OS がメッセージをキューに入れた段階で GetMessage してるプロセスにタスクスイッチする。
ディスクI/O しかり、socket しかり、タイマーしかり。
本当に CPU が何もしないときなら HALT してハードウェア割り込みを待ってる。

**デフォルトの名無しさん** · 2023/02/15(水) 16:44:48.20

WM_KEYDOWN
Ctrl+0（ゼロ）とかShift+0は来るのに、Ctrl+Shift+0は来ないのはなんでなん？

**デフォルトの名無しさん** · 2023/02/17(金) 22:01:39.95

定番のSleep(1)にこれだけ噛みつけるのも面白いな

**デフォルトの名無しさん** · 2023/02/18(土) 05:24:38.57

今時sleep(1)が定番とかw

**デフォルトの名無しさん** · 2023/02/18(土) 11:10:10.06

マルチコア、メニーコアでスレッド単体だけ見てもな

**デフォルトの名無しさん** · 2023/02/18(土) 16:35:58.18

イベント待ちはSleep(1)のポーリングでもどうでもいいと思うぞ
シングルスレッドで全部処理する場合問題はそこではないし
扱う内容によっては毛局スレッドを分けた方がいいって結論になる

**デフォルトの名無しさん** · 2023/02/18(土) 21:28:29.45

今時とかじゃない
>>463を読むほど笑えるという話

**デフォルトの名無しさん** · 2023/02/18(土) 23:58:40.40

イベントキャッチは1msほどの間隔の粒度でいいの？

**デフォルトの名無しさん** · 2023/02/19(日) 01:06:15.57

タイマーの精度が高くないからSleep(1)でも30msくらいウエイトかかるけどな

**デフォルトの名無しさん** · 2023/02/19(日) 01:28:55.07

1つの応答基準の60fpsが16.7ms間隔だからその間に処理が終わってれば常人の目には判らないし
待ち行列にメッセージが溜まってたりイベント処理が発生した場合、処理してる間にコンテキストスイッチが何度も起きて場合によっては1msなんて超えてくる
Sleep(1)はOSに時間を明け渡す気がありますよ程度の意味しかない

**デフォルトの名無しさん** · 2023/02/19(日) 01:46:44.83

マウス、キーボードの処理、ダイアログの更新のメッセージ処理くらいなら事足りる
昔のゲームもOllyDbgやIDAつかって覗いてみるとPeekMessageやGetTickCount等を使って一定時間間隔のメッセージ処理ループをやってた

**デフォルトの名無しさん** · 2023/02/19(日) 08:53:33.42

>>473
それはウィンドウメッセージ以外の処理を並行してやるためでしょ。
均等時間で処理を進めたいとかそういう事情が無ければ大人しくイベント待ちすればいいのに、そうせずわざわざ Sleep するとどんないいことがあるの？

**デフォルトの名無しさん** · 2023/02/19(日) 10:13:58.24

昔の知識否定されてファビョってるだけだろ
わざわざ昔のゲームとかw

**デフォルトの名無しさん** · 2023/02/19(日) 10:23:12.36

前レスよく読まなかったけど、GetMessage()で済むところをPeekMessage();Sleep(1);でループしてメッセージのポーリングするってことか。
なんでわざわざそんなことを？ｗ

**デフォルトの名無しさん** · 2023/02/19(日) 10:54:48.53

WinFormsのソースもPeekMessageでWindowメッセージがあればそれの処理、無ければタスクキュー処理って流れだったはず

**デフォルトの名無しさん** · 2023/02/19(日) 11:25:42.35

>>477
それと
> PeekMessage();Sleep(1);でループしてメッセージのポーリングする
が同じに見えるのか？

**デフォルトの名無しさん** · 2023/02/19(日) 11:36:42.06

>>478
Sleepは知らんがPeekMessageでブロックせずに他の定期処理挟むのは別に普通って言いたかっただけ

**デフォルトの名無しさん** · 2023/02/19(日) 14:38:47.15

>>479
> Sleepは知らんが
話の流れも読めないのかよ...

**デフォルトの名無しさん** · 2023/02/19(日) 14:39:32.86

そもそも454-457で解決してるのになんで盛り上がってきたんだw

**デフォルトの名無しさん** · 2023/02/24(金) 14:07:57.59

質問ですがOpen(Save)Dialog等でOFN_DONTADDTORECENTが無効の場合、この履歴情報はどこに保存されますか？

**デフォルトの名無しさん** · 2023/02/24(金) 14:25:10.37

すみません
エクスプローラの履歴を消したら消えました
質問を取り下げます

**デフォルトの名無しさん** · 2023/02/25(土) 14:25:14.46

Win32APIはC言語が前提
C++で同様なものはMFCであってます？

**デフォルトの名無しさん** · 2023/02/25(土) 14:47:53.07

>>484
C++でもWin32APIはWin32APIです。
MFCは別物。

元々はC/C++からWin32APIを呼び出す前提だったけど、
今はC#、Python、Rust等いろいろな言語から呼べるらしい。

**デフォルトの名無しさん** · 2023/02/25(土) 15:03:12.75

そうなんだ
サンクス

**デフォルトの名無しさん** · 2023/02/25(土) 17:08:15.41

GDI+　はリファレンスは C++のインターフェースだけど
細かくほぐしたら Cや他言語に対応できるのかな

**デフォルトの名無しさん** · 2023/02/25(土) 22:30:47.93

>>484
C++/WinRTもあるよ

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

>>484
MFCを使わせたかったのはVisual C++だった。

WindowsアプリケーションはC言語かC++を使うのが前提の歴史があって、MFCはWindows APIをラッピングしたものだった。

マイクロソフトはライブラリの作り方がよくわからず、MFCはコードが複雑になるだけのもの。

Java SEのライブラリが登場してから、マイクロソフトは失敗に気づいて.NET Frameworkを作ることになる。

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

>>489
MicrosoftのVisual C++のMFC
BorlandのC++ BuilderのVCL
当時のWindowsでのC++用クラスライブラリでのシェア競争の結果Borlandが敗れてMFCが主流になった
.NET FrameworkはもともとWindows DNA構想から産まれてきたものでMFCとは起源が別

**デフォルトの名無しさん** · 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しようぜ