X



Win32API質問箱 Build124
■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん 2017/11/11(土) 19:23:00.69ID:TpLoCFAx
Win32APIについての質問はこちらへどうぞ。

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

■過去スレ
Win32API質問箱 Build123
http://mevius.2ch.net/test/read.cgi/tech/1475897582/
Win32API質問箱 Build122
http://echo.2ch.net/test/read.cgi/tech/1451988219/
Win32API質問箱 Build121
http://echo.2ch.net/test/read.cgi/tech/1438695290/
Win32API質問箱 Build120
http://echo.2ch.net/test/read.cgi/tech/1428570962/

■関連スレ
Visual Studio 2017 Part4
http://mevius.2ch.net/test/read.cgi/tech/1509244956/
【C++】 DirectX初心者質問スレ Part40 【C】
http://mevius.2ch.net/test/read.cgi/tech/1474782237/
0630デフォルトの名無しさん2018/10/18(木) 16:38:48.09ID:rfYW9BA4
AVIStreamGetFrameOpenというAPIで「MPEG-4 Visual (XviD)」で
圧縮されたaviファイルを開きたいのですが可能でしょうか?
また上記が無理なら無圧縮以外の何かでエンコードされたものを
開きたいのですが何だったら可能なのかも教えてもらえないでしょうか?
AVIStreamGetFrameOpenは、2番目の引数にAVIGETFRAMEF_BESTDISPLAYFMTを指定すれば
完全な無圧縮以外でYUY2だけはいけました。
06316302018/10/18(木) 17:40:26.75ID:rfYW9BA4
調べていたらコーデックというのはAVIStreamGetFrameOpenで使用されたような古い形式と
メディアプレイヤーで使用されてるような新しい形式があるようですね…
つまりこの古いAPIだとそれように提供されているコーデックを探してインストールしないといけないという事になるでしょうか?
新しい形式を利用するプログラムを作った方がいいような気がしてきました。
06326302018/10/18(木) 18:23:13.79ID:rfYW9BA4
確かにVideo for Windows用のコーデックを探してきてインストールすれば動くようになりました。
解決はしたのですが他のPCでもその都度これをインストールしないといけないってのがどうも…
0633デフォルトの名無しさん2018/10/18(木) 18:34:46.06ID:LsEafRqd
そりゃコーデックのインストールは必須だよ
自前実装するとかなら別だけど
0634デフォルトの名無しさん2018/10/18(木) 18:57:16.36ID:rfYW9BA4
>>633
ただ新しいタイプの方(DirectShow)の方はメディアプレイヤーとかも入ってるので
デフォルトでも結構動きそうなのでそこがいいなと。
初回のプログラム起動時にコーデック用dllだけシステムフォルダに突っ込んでもいいのかな…
0635デフォルトの名無しさん2018/10/19(金) 12:08:49.41ID:jQ8EJjtV
>>632
ffmpeg
0636デフォルトの名無しさん2018/10/19(金) 17:30:46.21ID:HIw2KJmH
ところでMacとかだと64bit化で32bit打ち切りの方向みたいだけど、Winはまだまだ32bitもサポートしてくれるよね?
0637デフォルトの名無しさん2018/10/19(金) 19:13:40.82ID:HIw2KJmH
今のって64bit環境でエミュレーションしてるんだっけ?だから基本的にはずっと維持されるのかな?
0638デフォルトの名無しさん2018/10/20(土) 11:06:47.52ID:6LBMAo3K
WOW64だけ終了させるのは考えにくいね。
32bit過去資産を切り捨てるメリットが当面無い。


32bitって、一般的なアプリだけなら切る方向に動くのもあり得る話だけど、
工業系で周辺ハードウェアを制御するのに32bitドライバとか組み込んでて
不思議じゃないので簡単に切れるレベルじゃないかと。
ARM系なんか採用してたらムリじゃね。
128bitOSが出てきたときにようやく切るようになるんじゃないかな。

Macはそんな環境で動いているケースはほとんどないから問題ない気がする。
0639 ◆QZaw55cn4c 2018/10/20(土) 11:46:35.45ID:9jkSTDWo
>>638
>128bitOS
128ビットアーキテクチャーとか 128ビットOS とかは、ここ30年くらいは現れないのではないでしょうか…
0640デフォルトの名無しさん2018/10/20(土) 11:57:36.98ID:6LBMAo3K
8/16bit全盛時代、64bitを現実的に捉えてた人は居なかったしなあ。
128bitなんて遠い先だと今は思ってても、どうなるか分からんもんよ。
0641デフォルトの名無しさん2018/10/20(土) 12:18:25.97ID:u8BRF3D8
WOW64←32bit用のフォルダ
SYSTEM32←64bit用のフォルダ

では128bit化したときはどうなる?

WOW64←32bit用のフォルダ
WOW128←64bit用のフォルダ
SYSTEM32←128bit用のフォルダ

こうか?
0642デフォルトの名無しさん2018/10/20(土) 12:22:46.95ID:QqxqMvRx
WOW128←32bit用のフォルダ
WOW64←64bit用のフォルダ
SYSTEM32←128bit用のフォルダ

こうなる可能性も悪夢
0643デフォルトの名無しさん2018/10/20(土) 13:36:52.57ID:fOofNO0j
>>640
8/16bit全盛時代は32bitデスクトップコンピューターが
スーパーパソコンと言われることもあったなあ

32bit機なんて夢だった、64bit機なんて遠い未来に
実現するのかなあという感覚
0644デフォルトの名無しさん2018/10/20(土) 19:16:09.86ID:ZcZ7Cx83
>>638
そういうところがOSだけ最新なの使っているものなのか?
古いアプリケーションをずっと使っているようなところだとOSも昔のままな気がするけど

>>641
その時にはSYSTEM32って名称はやめていると思う
んで、64bit以前のアプリケーション互換云々は単純に仮想マシン環境下で動作させればいい
仮想マシン上でも十分な性能を得られるだろうし
0645デフォルトの名無しさん2018/10/20(土) 19:42:10.64ID:LsRLW+LD
128bitは多分こないんじゃないかなw
32bitとか64bitってメモリマッピングの領域の問題なんで
64bitなら4GByte×4GByteまでマッピング出来てしまうので
超絶高速SSDとかできてONメモリのように管理できるように
なっても64bit超えないような
0647デフォルトの名無しさん2018/10/20(土) 20:18:05.59ID:wecQHzx8
既にWindowsフォルダ配下はカオスだろ
M$よくこんなん管理できんなーと思ってたらやっぱり管理できてなかったみたいだな
0648デフォルトの名無しさん2018/10/20(土) 21:00:21.96ID:A+7VUlnR
アプリケーション的には
16bits → 64KB 死ぬほど不便
32bits → 4GB 快適
64bits → 16EB 贅沢できる
0649デフォルトの名無しさん2018/10/21(日) 02:36:06.52ID:fpcnU4T3
32bitアプリ使ってる人多いだろうから動かなくなったら苦情がめちゃくちゃ来そう。
0650デフォルトの名無しさん2018/10/21(日) 03:23:03.53ID:C+Apg5Hi
>>643
でもその頃、汎用機は32bit機械だったよ?
アドレッシングは24bitだったけど。

>>645
AS400は128bitと言ってもいいのでは。
むしろIoTとか言ってコンピュータ側のリーチが伸びてるから
単一レベル記憶で世界を管理しようとしたら、既にある技術で言えば
IPv6は128bitだし、既に128bitの世界はきてる気がするよ。
0651デフォルトの名無しさん2018/10/21(日) 05:03:20.85ID:5lMyjKAV
既存プロセスのウィンドウhwndに対するファイルのドラッグ&ドロップをマウスエミュレートを使わず実現するにはどうしたらよいですか?
過渡的な視覚効果であるドラッグは必要ないので、実質ドロップだけできればいいとは思うのですが。
0653デフォルトの名無しさん2018/10/21(日) 14:33:56.37ID:jYu3kmgI
>>650
個人が買えるPCの話だよ、その頃はPCで
32Bitアドレッシング24Bitなんて夢だった
0655デフォルトの名無しさん2018/10/21(日) 18:55:34.10ID:PdeVN0B9
> アプリケーション的には
> 16bits → 64KB 死ぬほど不便
> 32bits → 4GB 快適
> 64bits → 16EB 贅沢できる

8bitは ?
0656 ◆QZaw55cn4c 2018/10/21(日) 18:59:32.77ID:gNVlu9Yw
>>655
>8bitは ?
ほとんどの 8 ビットCPU のアドレス空間はすでに 16 ビットだったからなあ…
0658デフォルトの名無しさん2018/10/21(日) 20:51:33.47ID:3rYBWp0g
>>651
アプリケーション毎にドラッグをどう処理しているか不明だからマウスエミュが確実だと思うけど
0660デフォルトの名無しさん2018/10/21(日) 21:43:12.45ID:CMVET5pn
>>655
アドレスが8bitの汎用CPUなんてないんじゃない?
4004でさえアドレスは12bitだそうだ
06616512018/10/22(月) 01:10:30.37ID:zMz+R4iM
>>659
WM_DROPFILEはすでに試して失敗を確認済みです。
ドラッグ&ドロップの具体例をあげるとVisual Studio 2017 にファイルをドロップして開く処理をやりたいのだけど、
GlobalAlloc()、GlobalLock()、GlobalUnlock() などで作ったhDropをPostMessage(WM_DROPFILE)しているのだけど、まったく変化なし。
メモ帳notepad.exeの場合はPostMessage(WM_DROPFILE)で開けたのですが、VS2017と何が違うのやら。
0663デフォルトの名無しさん2018/10/22(月) 12:32:01.71ID:uugU0jx6
PIC のアドレスって何bitだっけ
68xx の memory mapped register とかは 8bit か
そもそもどうでもいい
0664デフォルトの名無しさん2018/10/22(月) 14:14:29.65ID:2rAhHCnw
>>648がネタだったらどうでもいいのだが
16bitのWindows3.1でも 1Mを越えるメモリーは使えたし、
32bitのWindowsのアプリケーションのメモリー空間は32bitではないし
64bitのWindowsのアプリケーションのメモリー空間は64bitではない
0665デフォルトの名無しさん2018/10/22(月) 15:48:26.25ID:H1W4+XYR
アセンブラで書いてるのかω
0666デフォルトの名無しさん2018/10/22(月) 18:19:05.88ID:x0pcGzlw
8bit→16bit 前世代の256倍
16bit→32bit 前世代の65536倍
32bit→64bit 前世代の4294967296倍
64bit→128bit 前世代の18446744073709551616倍
で各時代のジャンプしてる倍数が全然リニアじゃない
128bitは俺らが生きてる間に実現しない
0667デフォルトの名無しさん2018/10/22(月) 18:27:51.91ID:x0pcGzlw
つまりは
8bit倍→16bit倍→32bit倍→64bit倍 とくるから
だんだん間隔が長くなって正常
64bit(前世代の32bit倍)ですら途方もなくて持て余す(実際48bit)のに
64bit倍なんてのは途方もないものはどうしようもない
永遠に到達しないと思っても問題ないくらいに天文学的数値
0668デフォルトの名無しさん2018/10/22(月) 18:38:09.95ID:N4Dlk9u9
そうでもない
進化は指数関数的に変化するから
0669デフォルトの名無しさん2018/10/22(月) 18:44:02.73ID:VafFZz5P
CPU取り扱いビット数は、なにもメモリー空間だけの問題じゃないと思うが。
なんにしても、ないもの語るのは不毛な話だわ。
0671デフォルトの名無しさん2018/10/22(月) 19:06:40.33ID:x0pcGzlw
CPUのビット数と言ったらやっぱりメモリ空間だろ
俺らに関係する互換性の意味でもさ

>>668
bit数が一つ増えると2倍になるが、そのbit数も2倍で増やしていくから
指数関数の指数関数でとんでもない速度で増加する
一方でムーアの法則はただの指数関数だから
割り算すると指数関数が残る
というのが>>666-667の説明
0672デフォルトの名無しさん2018/10/22(月) 22:15:29.36ID:iXt7ySqh
さすがに64bitアドレスを使い切ることは無いべ?
下手すると64bit個の原子は目で見えるサイズじゃないか?

2^64=1.8446744e+19
アボガドロ数=6.0221409e+23/1mol

砂粒くらいはありそうだよな?
0674デフォルトの名無しさん2018/10/22(月) 23:05:44.67ID:CgLRMpn3
過去からbit数が上がる際にはメモリー空間に限定した話ではなくて
「パフォーマンスが上がる」というまずは大ざっぱな喧伝がなされてた
メモリー空間はもちろん広がるが、そんな限定的な事じゃない様々な性能アップ要素で
話がされたもので、今になってメモリー空間だけに絞った話にしかならないのは
その話している人の経験や視野が狭すぎるのが原因ではなかろうか
0675デフォルトの名無しさん2018/10/22(月) 23:08:02.77ID:1Kkbm3du
>>664
アプリケーションの話をしてんだから
8086 死ぬほど不便 あってるじゃん

32bitのWindowsのアプリケーションのメモリー空間は32bitじゃん?
36bit使える?32bitアプリが。
0677デフォルトの名無しさん2018/10/23(火) 02:55:48.42ID:sn2WQhnj
アーキテクチャや最適化とかあらゆる要素を全く無視して
一部だけ切り取って主題の否定に終始しておけば勝つから頑張れ
06786642018/10/23(火) 10:09:02.12ID:GIVzaW28
>>675
Windows3.1は8086では動かない
多くの32bit Windowsアプリケーションのメモリー空間は 2G (31bits)
0679デフォルトの名無しさん2018/10/23(火) 11:47:28.84ID:hJha4BQY
何でCPUのbit数の話がメモリのサイズ限定になるってそりゃ当たり前ここはプログラム板だから
ポインタのサイズがいくらになるかが互換性の面で最大限問題なんだよ
互換性の面でな
0680デフォルトの名無しさん2018/10/23(火) 11:49:19.92ID:hJha4BQY
しかもここはWin32APIのスレで
128bitのWinAPIはいつ出るかって話だから
ポインタのサイズ=メモリ空間のサイズの
話になっていくのは当たり前
0681デフォルトの名無しさん2018/10/23(火) 12:48:48.94ID:joSIbJ7d
>>675
128bitマシンがあっても
FDDだったら死ぬほど不便だな
0682デフォルトの名無しさん2018/10/23(火) 15:26:03.23ID:WBybiFHu
>>681
オンラインストレージもすべてアドレッシングされてるような美来を考えると、
そんなに不便でもないような気も少し。
0683デフォルトの名無しさん2018/10/23(火) 15:28:44.02ID:sn2WQhnj
>>679-680
> 何でCPUのbit数の話がメモリのサイズ限定になるってそりゃ当たり前ここはプログラム板だから

プログラムの話でCPUの基本であるアセンブラ・命令セット・レジストリやアーキテクチャなどをすっぱり抜く意味はなんですか。


> 128bitのWinAPIはいつ出るかって話だから

>>636-640
「Win32APIのサポートはいつまでか」〜
から、
「128bit CPU・OSが出たら」〜

の話であって、128bitのWinAPIはいつ出るかって話ではありません。
しかし、「128bit CPU・OSが出たら」に対してメモリマップの問題だと言い出したのは>>645です。
この主張に対して、メモリ限定の話になっているのがおかしいというのが本反論です。

あくまでも「128bit CPU・OSが出たら」が基本の話で、あなたの言う「128bitのWinAPI」は
話の本筋ではありませんし、そもそも話が出ていません。

アドレッシングの話題は話題でやればいいですが、これを論拠に「だから次はない」
なんてのはナンセンスというだけの話です。
0684デフォルトの名無しさん2018/10/23(火) 16:08:56.16ID:hJha4BQY
レジスタ長やら命令セットの話なら既にAVX512とかがあるでしょ
ただこれとWin32APIは関係ないでしょ?
x64が続く限りWin32APIのサポートがずっとあるのは明白だし
(あえて命令セットを変える意味がないでしょ・・・何の意味が?)
もし変えるとしたら128bit化の時だろうけど
まず生きてる間には来ないよねって話でしょ
0685デフォルトの名無しさん2018/10/23(火) 16:18:21.83ID:hJha4BQY
ちなみに128bit化に伴って32bitプロセスがサポートされなくなる可能性は有る
何故なら128bitは100年後か1000年後かあるいは永遠に来ないか
そのぐらいの未来になったら32bitプロセスはすっかりレガシーになってて
サポートする意味が無いかもしれん、わからんがな
ただそんな未来は生きてる間に来そうにない、という事で
Win32APIのサポートが無くなることはないだろうという事を述べておる
0686デフォルトの名無しさん2018/10/23(火) 17:00:05.35ID:yFsvvFWj
>生きてる間には来ない

来たらどうするか(どうなるか)って話をしてるんだろ

空気読めないアスペか?
0689デフォルトの名無しさん2018/10/23(火) 17:55:28.41ID:hJha4BQY
計算したら来ないし
遠い未来すぎて今と状況が違いすぎるからなんとも

結局は32bitをサポートするかは技術的というより時間的要因とうか周りからの要求で決まるわけで
例えばもし10年後に128bitになるなら32bitをサポートするようにCPUを作るだろうし
100年後だったらもはやレガシーすぎてサポートしないかもだし
(その場合はソフトエミュレーションかな)
結局は問題ないだろうということ
俺らが困らないようにしてくれるさ
IntelがItaniumを作って広げようとしても、AMDがx86作ってそっちが選ばれたしな
互換が無くなって一番困るのは俺らよりマイクロソフトだから何とかしてくれるのだわ
0691デフォルトの名無しさん2018/10/23(火) 18:15:44.57ID:d491RiZs
> レジスタ長やら命令セットの話なら既にAVX512とかがあるでしょ
AVXのときにAVX512なんて絶対来ないとか言ってたか?
次がどうなるとお前が決める事ではない

> ただこれとWin32APIは関係ないでしょ?
関係ないからこそWin32APIだけの話題で次があるないを確定づける論拠にするのに意味がない
0693デフォルトの名無しさん2018/10/23(火) 20:21:56.29ID:tecJ1BiK
32/64だとポインタをDWORDに放り込んで処理してるのとかあるからな
0694デフォルトの名無しさん2018/10/23(火) 23:44:40.09ID:volyHHZE
window handleとかはx64だと64bit幅だけど、wow64でもそのまま扱えるように32bit内の値しか設定されないとかあるね。
06956872018/10/24(水) 06:38:30.05ID:UmzQGEnh
>>682が書いているように
I/Oの中身がすべてアドレスでとれるようなマッピングのこと
他のPCもまるごとアドレシングされているような世界
0696デフォルトの名無しさん2018/10/24(水) 11:37:09.95ID:XOgiiIOy
>>692-693
rubyは困りそうω
0697デフォルトの名無しさん2018/10/24(水) 13:36:44.56ID:42dinMX8
>>696
perl もだよ。
perlでライブラリWin32APIで構造体をマッピングする場合、
構造体のメンバー変数のアラインメントを自力で解決しなければならず、
32bit版と64bit版でオフセットを適切に切り替えるコードが必要。
0698 ◆QZaw55cn4c 2018/10/25(木) 00:37:44.65ID:yGYVJ0zR
http://wisdom.sakura.ne.jp/system/
0699デフォルトの名無しさん2018/10/25(木) 11:37:51.73ID:5Cy/pQlU
えらい古いな
っていうか 赤坂玲音 って糞筆者の筆頭じゃねーか
QZ って 赤坂玲音 だったのか?
0700デフォルトの名無しさん2018/10/27(土) 13:09:18.62ID:NcyVMn+k
今や当たり前のようになった入力補完候補の動的羅列を従来のコンボボックスのドロップダウンリストでやってみた。
作成済みコンボボックスは途中でオーナードローにスタイル変更できないので、毎回リストを再構築することにした。
ドロップダウンリストの再構築に時間がかかっているように見えたので、
試しにリストをSetRedraw(FALSE)で描画せずに再構築したところ、まったく時間がかからなくなった。
リストアイテムに追加していく処理のたびに描画で重くなっていただけだった。


結論:
ドロップダウンリストの動的変更はSetRedraw(FALSE)で見かけ上は高速に実行可能。
リスト再構築が終わったらSetRedraw(TRUE)で再び描画できるようにして RedrawWindow() などを呼べばOK。
0701デフォルトの名無しさん2018/10/27(土) 13:29:57.46ID:R2aCZi1a
おめ子
07037002018/10/28(日) 04:05:03.07ID:y4CTIPMK
>>702
別にMFCの話したかったわけじゃないんだが。
リスト破棄とアイテム追加のたびに描画処理が行われるとどうしてもアイテム更新完了が遅くなる。
オーナードローできない汎用のリストコントロールのアイテム更新はSetRedraw()つまりSendMessage(WM_SETREDRAW)で描画抑止すれば高速実行できる、というのが主旨。
0705デフォルトの名無しさん2018/10/28(日) 22:57:05.89ID:G0OjLYsX
>>691
違うって
AVXだろうがAVX512だろうがAVX1024だろうが
ただの拡張命令だから何がこようがどうでもよいけど
ポインタのサイズだけは命令セット全体に影響して互換性の面で問題が出るから
プログラマとしてそこが真っ先に気になるのは当たり前だろうよ

そんでポインタのサイズが64bitで足りなくなる事は生きてる間には無さそうということと
今現在64bit版のWin32APIのサポートがあることを合わせて考えて
Win32APIのサポートの心配するより自分の寿命の心配したほうが良いってことに
ただし、将来Windowsが無くなったら知らんが
0707デフォルトの名無しさん2018/10/28(日) 23:34:05.53ID:X0Sl4ey0
すみません
アナルに今電極を差してみているのですが
どのくらいの電圧が人間の限界なのかがよく分かっていません
参考までにお教え願えませんでしょうか?
0710デフォルトの名無しさん2018/10/29(月) 11:33:26.98ID:VxCr7qKV
>Win32APIのサポートの心配するより自分の寿命の心配したほうが良い

どっちも心配
0711 ◆QZaw55cn4c 2018/10/29(月) 19:36:35.79ID:MQrExvvX
>>699
>赤坂玲音 って糞筆者の筆頭
kwsk
0713デフォルトの名無しさん2018/10/30(火) 14:43:24.71ID:p4LrBCE7
橋本 和明
山本 洋介山
こいつらよりまし
0716デフォルトの名無しさん2018/10/31(水) 01:20:17.24ID:OyhA4eFa
>>713
1冊じゃないのが許せないよな

赤坂玲音って会社員経験がないんだっけ
確かにそんな感じはする
0717651,6612018/11/04(日) 09:16:05.57ID:muyEcRRg
SendInput() にINPUT配列を渡してドラッグ&ドロップをエミュレートすることで対応できました。配列の要素は以下2つ。
ドラッグ開始位置で MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE | MOUSEEVENTF_LEFTDOWN
ドロップ位置で MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE | MOUSEEVENTF_LEFTUP

mouse_event()と違ってSendInput()はユーザーのマウス操作の影響を受けづらいはずですが、
マウス移動とマウスボタン操作を別のINPUT要素に入れるとユーザーのマウス操作が入り込んでしまうので、要注意でした。
0718 ◆QZaw55cn4c 2018/11/04(日) 10:52:13.06ID:4sZQO68Y
>>716
>赤坂玲音って会社員経験がないんだっけ
書籍を執筆するのに会社員経験は必要ですか?
0719デフォルトの名無しさん2018/11/04(日) 11:18:54.43ID:kSTg14OV
いるわけねーだろ。バカかよw
って馬鹿だからいつまでもくだらない話題ひっぱってんだろうな
0722デフォルトの名無しさん2018/11/04(日) 14:04:57.01ID:5RY1Lh2I
エラーを調べるには関数を呼びます
0723デフォルトの名無しさん2018/11/04(日) 15:45:01.93ID:I4L5mfdv
せめてヒントを書いとけよ

ヒント:最後のエラーを取得する関数です
とか
0725デフォルトの名無しさん2018/11/04(日) 18:11:10.68ID:rLQVzKFu
MSが保守投げだしたくなる気持ちは判る
0727デフォルトの名無しさん2018/11/04(日) 19:09:01.33ID:I4L5mfdv
>>724
www

まいりました
0728 ◆QZaw55cn4c 2018/11/04(日) 19:41:55.05ID:4sZQO68Y
>>720
>GetMessageの戻り値をちゃんと調べる

当然なのでは?

while(GetMessage(&msg , NULL , 0 , 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}

メッセージループを抜けるかどうかは、GetMessage() を調べでもしないかぎり分かりようがないのでは?
■ このスレッドは過去ログ倉庫に格納されています

ニューススポーツなんでも実況