Win32API質問箱 Build124
■ このスレッドは過去ログ倉庫に格納されています
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/ 既存プロセスのウィンドウhwndに対するファイルのドラッグ＆ドロップをマウスエミュレートを使わず実現するにはどうしたらよいですか？
過渡的な視覚効果であるドラッグは必要ないので、実質ドロップだけできればいいとは思うのですが。 >>649
そもそもVisual Studioが32bitだから32bit打ち切ったら開発できなくなるし w >>650
個人が買えるPCの話だよ、その頃はPCで
32Bitアドレッシング24Bitなんて夢だった > アプリケーション的には
> 16bits → 64KB 死ぬほど不便
> 32bits → 4GB 快適
> 64bits → 16EB 贅沢できる
8bitは ? >>655
＞8bitは ?
ほとんどの 8 ビットCPU のアドレス空間はすでに 16 ビットだったからなあ… >>651
アプリケーション毎にドラッグをどう処理しているか不明だからマウスエミュが確実だと思うけど >>651
ttps://docs.microsoft.com/en-us/windows/desktop/shell/wm-dropfiles >>655
アドレスが8bitの汎用CPUなんてないんじゃない？
4004でさえアドレスは12bitだそうだ >>659
WM_DROPFILEはすでに試して失敗を確認済みです。
ドラッグ＆ドロップの具体例をあげるとVisual Studio 2017 にファイルをドロップして開く処理をやりたいのだけど、
GlobalAlloc()、GlobalLock()、GlobalUnlock() などで作ったhDropをPostMessage(WM_DROPFILE)しているのだけど、まったく変化なし。
メモ帳notepad.exeの場合はPostMessage(WM_DROPFILE)で開けたのですが、VS2017と何が違うのやら。 WM_DROPFILEの他に、OLE Drag&Dropもあるでよ PIC のアドレスって何bitだっけ
68xx の memory mapped register とかは 8bit か
そもそもどうでもいい >>648がネタだったらどうでもいいのだが
16bitのWindows3.1でも 1Mを越えるメモリーは使えたし、
32bitのWindowsのアプリケーションのメモリー空間は32bitではないし
64bitのWindowsのアプリケーションのメモリー空間は64bitではない 8bit→16bit 前世代の256倍
16bit→32bit 前世代の65536倍
32bit→64bit 前世代の4294967296倍
64bit→128bit 前世代の18446744073709551616倍
で各時代のジャンプしてる倍数が全然リニアじゃない
128bitは俺らが生きてる間に実現しない つまりは
8bit倍→16bit倍→32bit倍→64bit倍 とくるから
だんだん間隔が長くなって正常
64bit(前世代の32bit倍)ですら途方もなくて持て余す(実際48bit)のに
64bit倍なんてのは途方もないものはどうしようもない
永遠に到達しないと思っても問題ないくらいに天文学的数値 CPU取り扱いビット数は、なにもメモリー空間だけの問題じゃないと思うが。
なんにしても、ないもの語るのは不毛な話だわ。 CPUのビット数と言ったらやっぱりメモリ空間だろ
俺らに関係する互換性の意味でもさ
>>668
bit数が一つ増えると2倍になるが、そのbit数も2倍で増やしていくから
指数関数の指数関数でとんでもない速度で増加する
一方でムーアの法則はただの指数関数だから
割り算すると指数関数が残る
というのが>>666-667の説明 さすがに64bitアドレスを使い切ることは無いべ？
下手すると64bit個の原子は目で見えるサイズじゃないか？
2^64=1.8446744e+19
アボガドロ数=6.0221409e+23/1mol
砂粒くらいはありそうだよな？ みんながそう思ったら、IPv6は128bitにしなかっただろうね :-p 過去からbit数が上がる際にはメモリー空間に限定した話ではなくて
「パフォーマンスが上がる」というまずは大ざっぱな喧伝がなされてた
メモリー空間はもちろん広がるが、そんな限定的な事じゃない様々な性能アップ要素で
話がされたもので、今になってメモリー空間だけに絞った話にしかならないのは
その話している人の経験や視野が狭すぎるのが原因ではなかろうか >>664
アプリケーションの話をしてんだから
8086 死ぬほど不便 あってるじゃん
32bitのWindowsのアプリケーションのメモリー空間は32bitじゃん？
36bit使える？32bitアプリが。 >>674
80286とi386だと、クロックが同じだと80286の方が速いこともあったよ？ アーキテクチャや最適化とかあらゆる要素を全く無視して
一部だけ切り取って主題の否定に終始しておけば勝つから頑張れ >>675
Windows3.1は8086では動かない
多くの32bit Windowsアプリケーションのメモリー空間は 2G (31bits) 何でCPUのbit数の話がメモリのサイズ限定になるってそりゃ当たり前ここはプログラム板だから
ポインタのサイズがいくらになるかが互換性の面で最大限問題なんだよ
互換性の面でな しかもここはWin32APIのスレで
128bitのWinAPIはいつ出るかって話だから
ポインタのサイズ=メモリ空間のサイズの
話になっていくのは当たり前 >>675
128bitマシンがあっても
FDDだったら死ぬほど不便だな >>681
オンラインストレージもすべてアドレッシングされてるような美来を考えると、
そんなに不便でもないような気も少し。 >>679-680
> 何でCPUのbit数の話がメモリのサイズ限定になるってそりゃ当たり前ここはプログラム板だから
プログラムの話でCPUの基本であるアセンブラ・命令セット・レジストリやアーキテクチャなどをすっぱり抜く意味はなんですか。
> 128bitのWinAPIはいつ出るかって話だから
>>636-640
「Win32APIのサポートはいつまでか」〜
から、
「128bit CPU・OSが出たら」〜
の話であって、128bitのWinAPIはいつ出るかって話ではありません。
しかし、「128bit CPU・OSが出たら」に対してメモリマップの問題だと言い出したのは>>645です。
この主張に対して、メモリ限定の話になっているのがおかしいというのが本反論です。
あくまでも「128bit CPU・OSが出たら」が基本の話で、あなたの言う「128bitのWinAPI」は
話の本筋ではありませんし、そもそも話が出ていません。
アドレッシングの話題は話題でやればいいですが、これを論拠に「だから次はない」
なんてのはナンセンスというだけの話です。 レジスタ長やら命令セットの話なら既にAVX512とかがあるでしょ
ただこれとWin32APIは関係ないでしょ？
x64が続く限りWin32APIのサポートがずっとあるのは明白だし
(あえて命令セットを変える意味がないでしょ・・・何の意味が？)
もし変えるとしたら128bit化の時だろうけど
まず生きてる間には来ないよねって話でしょ ちなみに128bit化に伴って32bitプロセスがサポートされなくなる可能性は有る
何故なら128bitは100年後か1000年後かあるいは永遠に来ないか
そのぐらいの未来になったら32bitプロセスはすっかりレガシーになってて
サポートする意味が無いかもしれん、わからんがな
ただそんな未来は生きてる間に来そうにない、という事で
Win32APIのサポートが無くなることはないだろうという事を述べておる >生きてる間には来ない
来たらどうするか(どうなるか)って話をしてるんだろ
空気読めないアスペか？ I/Oがすべてマッピングされている世界はたぶんたのしい 計算したら来ないし
遠い未来すぎて今と状況が違いすぎるからなんとも
結局は32bitをサポートするかは技術的というより時間的要因とうか周りからの要求で決まるわけで
例えばもし10年後に128bitになるなら32bitをサポートするようにCPUを作るだろうし
100年後だったらもはやレガシーすぎてサポートしないかもだし
(その場合はソフトエミュレーションかな)
結局は問題ないだろうということ
俺らが困らないようにしてくれるさ
IntelがItaniumを作って広げようとしても、AMDがx86作ってそっちが選ばれたしな
互換が無くなって一番困るのは俺らよりマイクロソフトだから何とかしてくれるのだわ ただ、Windowsが無くなればWin32APIも無くなるが。。。 > レジスタ長やら命令セットの話なら既にAVX512とかがあるでしょ
AVXのときにAVX512なんて絶対来ないとか言ってたか？
次がどうなるとお前が決める事ではない
> ただこれとWin32APIは関係ないでしょ？
関係ないからこそWin32APIだけの話題で次があるないを確定づける論拠にするのに意味がない 32/64だとポインタをDWORDに放り込んで処理してるのとかあるからな window handleとかはx64だと64bit幅だけど、wow64でもそのまま扱えるように32bit内の値しか設定されないとかあるね。 >>682が書いているように
I/Oの中身がすべてアドレスでとれるようなマッピングのこと
他のPCもまるごとアドレシングされているような世界 >>696
perl もだよ。
perlでライブラリWin32APIで構造体をマッピングする場合、
構造体のメンバー変数のアラインメントを自力で解決しなければならず、
32bit版と64bit版でオフセットを適切に切り替えるコードが必要。 http://wisdom.sakura.ne.jp/system/ えらい古いな
っていうか 赤坂玲音 って糞筆者の筆頭じゃねーか
QZ って 赤坂玲音 だったのか？ 今や当たり前のようになった入力補完候補の動的羅列を従来のコンボボックスのドロップダウンリストでやってみた。
作成済みコンボボックスは途中でオーナードローにスタイル変更できないので、毎回リストを再構築することにした。
ドロップダウンリストの再構築に時間がかかっているように見えたので、
試しにリストをSetRedraw(FALSE)で描画せずに再構築したところ、まったく時間がかからなくなった。
リストアイテムに追加していく処理のたびに描画で重くなっていただけだった。
結論：
ドロップダウンリストの動的変更はSetRedraw(FALSE)で見かけ上は高速に実行可能。
リスト再構築が終わったらSetRedraw(TRUE)で再び描画できるようにして RedrawWindow() などを呼べばOK。 >>702
別にMFCの話したかったわけじゃないんだが。
リスト破棄とアイテム追加のたびに描画処理が行われるとどうしてもアイテム更新完了が遅くなる。
オーナードローできない汎用のリストコントロールのアイテム更新はSetRedraw()つまりSendMessage(WM_SETREDRAW)で描画抑止すれば高速実行できる、というのが主旨。 >>702
Win32API的には SetWindowRedraw (WM_SETREDRAW) でOK >>691
違うって
AVXだろうがAVX512だろうがAVX1024だろうが
ただの拡張命令だから何がこようがどうでもよいけど
ポインタのサイズだけは命令セット全体に影響して互換性の面で問題が出るから
プログラマとしてそこが真っ先に気になるのは当たり前だろうよ
そんでポインタのサイズが64bitで足りなくなる事は生きてる間には無さそうということと
今現在64bit版のWin32APIのサポートがあることを合わせて考えて
Win32APIのサポートの心配するより自分の寿命の心配したほうが良いってことに
ただし、将来Windowsが無くなったら知らんが AVXとか持ち出した人自身がどうでもいいとか言い出したよ すみません
アナルに今電極を差してみているのですが
どのくらいの電圧が人間の限界なのかがよく分かっていません
参考までにお教え願えませんでしょうか？ >>707
今差しているんだろ？
限界になるまで電圧上げてみればいい >Win32APIのサポートの心配するより自分の寿命の心配したほうが良い
どっちも心配 >>699
＞赤坂玲音 って糞筆者の筆頭
kwsk >>713
1冊じゃないのが許せないよな
赤坂玲音って会社員経験がないんだっけ
確かにそんな感じはする SendInput() にINPUT配列を渡してドラッグ＆ドロップをエミュレートすることで対応できました。配列の要素は以下2つ。
ドラッグ開始位置で MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE | MOUSEEVENTF_LEFTDOWN
ドロップ位置で MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE | MOUSEEVENTF_LEFTUP
mouse_event()と違ってSendInput()はユーザーのマウス操作の影響を受けづらいはずですが、
マウス移動とマウスボタン操作を別のINPUT要素に入れるとユーザーのマウス操作が入り込んでしまうので、要注意でした。 >>716
＞赤坂玲音って会社員経験がないんだっけ
書籍を執筆するのに会社員経験は必要ですか？ いるわけねーだろ。バカかよｗ
って馬鹿だからいつまでもくだらない話題ひっぱってんだろうな GetMessageの戻り値をちゃんと調べる良識人やぞ せめてヒントを書いとけよ
ヒント：最後のエラーを取得する関数です
とか >>720
＞GetMessageの戻り値をちゃんと調べる
当然なのでは？
while(GetMessage(&msg , NULL , 0 , 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
メッセージループを抜けるかどうかは、GetMessage() を調べでもしないかぎり分かりようがないのでは？ while(GetMessage(&msg , NULL , 0 , 0) < 0) {
boolじゃないからな そんなコードばっか書いてるからいつまでも使えないんだよｗ >>734
エラーの時だけループするのが正しいんですね
勉強になります while(BOOL bRet = GetMessage(&msg , NULL , 0 , 0)) {
if (bRet < 0) {
MessageBox(NULL, TEXT("異常終了してやんのw ぷぷぷ"), NULL, 0);
break;
}
TranslateMessage(&msg);
DispatchMessage(&msg);
} 無効ポインタを渡してしまった以外にエラーを起こす事あるか？ Windows互換を目指すReactOS、
いよいよ明日の夜、リリースです。よろしくね。 C/C++では、メッセージループの異常終了に加えてC++の例外と、構造化例外による異常終了があるよ。 >>739
そんなもんMSの中の人にしかわからんだろ while(TRUE){
try{
while(BOOL bRet = GetMessage(&msg , NULL , 0 , 0)) {
if (bRet < 0) {
MessageBox(NULL, TEXT("異常終了してやんのw ぷぷぷ"), NULL, 0);
break;
}
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}catch(std::exception &e){
MessageBox(NULL, TEXT("例外補足してやんぜw ぷぷぷ"), NULL, 0);
}
} メッセージループを終了しても永久ループから脱出できない罠 std::exception はスレチだし、WndProcから送出してよい例外はWindowsの構造化例外のみだし、送出された構造化例外をWinMainで処理してはいけない ボケなのマジなのかわからんコードを貼ってるやつはなんなの ■ このスレッドは過去ログ倉庫に格納されています
