Win32API質問箱 Build123©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
Win32APIについての質問はこちらへどうぞ。
■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。
英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで
■過去スレ
Win32API質問箱 Build122
http://echo.2ch.net/test/read.cgi/tech/1451988219/ >>739
XPのPCがないので検証できないですね。
DDOS対策だとすると、成す術なしでしょうか･･･。
>>740
ジャンボフレームの設定は、Surfaceではできないみたいです。
仮にジャンボフレームじゃないにしても、今の帯域は小さすぎる気がします。
>>742
送り側はsendto()で、一度に送れる最大サイズの65507バイトで送ってます。 >>744
むしろ一度に送りすぎでは?
etherのフレームに入り切らないとipレベルでフラグメンテーションを起こして余計遅くなることもある。
1500-20-8=1472以下だとどうなる? >>744
ソケットのバッファが溢れているのかもしれない。UDPだからsendしても黙って破棄されうる。これが原因だったらsetsockoptで送信、受信のバッファを大きくすれば良い。
また、UDPではOSが送信速度の調節をしないから、アプリケーション側で一定の速度でsendしないと途中のデバイスや受信側で破棄されることもある。
例えば、5Mbpsで送っているつもりでも、10ms間に500Mbpsで送り、後の990msは何もしていない可能性がある。その場合途中のWi-Fiルータのバッファが溢れるかもしれない。
送信用のスレッドを作り、send毎に経過時間と送信量を調べ、適当にsleepさせれば良い。 LANケーブルの方は10Mbpsでリンクアップしてない？ 本日、色々検証してみまして、分かったことを書きます。
送信側（優先）のPCで、whileループでひたすらsendto()しまくる単純なプログラムを動かしたところ、
何と1Gbps近く出ました！
動画圧縮・送信アプリで送信制限があるかに見えたのは、
単にエンコードのAPIが、一定以上のビットレートではデータサイズが飽和しているだけのようです。
このアプリを複数起動したところ、1プロセス×起動数分の帯域（12Mbps等）をちゃんと消費しました。
しかし、一方の受信側（無線）のタブレットPCでは、whileループでひたすらrecvfrom()しまくっても
5Mbps程度でやはり頭打ちしました。
これらはすべてUDPでの送受信ですが、
試しにTCPではどうか検証してみたところ、
フリーのFTP転送アプリで、送受信ともに、何と200Mbpsくらい出ました！
そんなバカな、と思い、自分でTCP送受信だけをひたすら行う単純なプログラムを書いて実行してみたところ、
200Mbpsには至らなかったものの、26Mbpsくらいまでは送受信ともに出せました。
なお、帯域を大きくすればするほど、送信に失敗する確率が高まる傾向が見られました。
これはTCPで見られる、受信側のバッファ枯渇によるものと思われます。
アプリ側でsetsockopt()で受信バッファを拡張してやると改善し、上記bpsに至りました。
FTP転送アプリがなぜ200Mbpsも叩き出せたかは分かりませんが、
今回の動画送受信アプリでは26Mbpsでも十分な帯域なので、結果的にはUDPからTCPに変更ことで対策が完了しました。 今回の検証で、以下のような仮説が立ったのですが、いかがでしょうか？
・11acにまで広帯域化し、TCPの再送制御等のオーバーヘッドが相対的に小さくなった
・11acで帯域は向上し、エラーレートも抑えられているものの、パケットロスする絶対数（機会）は
増加しているため、UDPには向かなくなっている
こうなると、「大容量のデータを効率的に送受信」というUDPのメリットは失われ、
ブロードキャスティングでデータ共有の利点が残る程度になるのかなぁ、という感じです。
この考察は的を射ているでしょうか？
だとしたら、業界では知られてることなんでしょうかね？ >>750
①TCPのオーバーヘッドは送受信の処理が重いことが主で、別にそれほど帯域を浪費する訳ではない。
ヘッダによる消費は、UDPだと1500バイト中28バイト、TCPだと1500バイト中40バイト。TCPだと適宜ACKが返ってくるが、それも各パケット数十バイト。
送受信側の処理速度向上が大きい。
②UDP向きかどうかは当然何をしたいかに依る。
TCPの処理が邪魔になる場合(遅延やパフォーマンス等の理由で)、「何もしない」UDP上に独自の実装をする。TCPで問題ないならTCPで良い。
信頼できるストリーム通信が必要なら、結局UDP上にTCPもどきを作ることになるだけ。
③TCPの欠点に、RTTが大きいと遅くなることがある。海外との大量のファイル転送はUDP上の独自プロトコルで行ったりする。あと、TCPoverTCPはパフォーマンスが劣化するから、VPNやトンネリングはUDP上が良い。
また、コネクションレスであることは、NATやFWを越える時に便利だったりする。
④普通、何もしないUDPは、余計な処理をするTCPより遅くはならない。UDPで5Mbpsしか出ないのは、どこかのバッファが溢れているか、大きすぎるデータをsendしてフラグメンテーションを起こしているかどちらかの可能性が高い。 >>750
＞・11acで帯域は向上し、エラーレートも抑えられているものの、パケットロスする絶対数（機会）は
＞増加しているため、UDPには向かなくなっている
そんなにパケットロスしているとtcpも速度出ないですよ。
原理的には、制御して再送する分だけudpより遅くなるでしょう。
udp で速度が出ないのは主として送受信側のバッファ溢れでしょうから、
・送信側は溢れないレートで送信する
例えば帯域1GHz WiFi で 1Gbps で送信したら帯域を食い潰して受信側へ再送出できませんよね。
ケーブルの場合と違って電波は PC->基地局-> 受信側とairを2回経由します。
あまり大量に送ると基地局まで届いてもそこでドロップされます。
・read側はなるべくread I/O を発行しっぱなしにしてあげる
スレッド使うなどカーネルの受信バッファあてにしないで頑張る。 >>750
> 今回の検証で、以下のような仮説が立ったのですが、いかがでしょうか？
全然的はずれ 詳細なご助言、ありがとうございます。
ソケットプログラミングを舐めてました･･･。
勉強します。 Windows10の環境で、ShowCursor(FALSE);、ShowCursor(TRUE);
が何故か動かないですが、原因わかりますか？代用のＡＰＩってありますか？
カーソルの形状を透明に置き換えるしかないかな。。。 >>756
自分のプログラムではWindows10で動いてるよ。
複数回呼んだりしてない？
ShowCursor()は内部の参照カウントみたいなのをインクリメント/デクリメントして、
0以上かどうかで表示/非表示が変わる。
確実にやるならwhile文で戻り値（カウント値）をチェックしてやる。 自分のアプリ内だけ消したいとかならWM_SETCURSORでSetCursorにぬるぽ渡してるなあ 動かない原因がわかりました。。。
自分のＷＩＮＤＯＷを表示していない場合、カーソル非表示にならないっぽいです。
ジョイスパッドで操作するマウスを作っていて、マウスを移動した後で、
自動的にマウスカーソルの表示/非表示したかったのですが、
自分のウインドウを表示していないためにうまくいかない；；
カーソルの形状変えて回避を試すか、透過ウインドとかで回避？ どうだったかなぁ
グローバルにマウスカーソルを消す方法はあったかなぁ
相当な迷惑行為だからなぁ
そんな事をしたい奴も居ないだろうしなぁ SetSystemCursorで一応変更できるけど完璧にはできない マウスの件ですが、サイズ1x1のウインドウを作って、WM_TIMERでウインドウを追尾するようにして対処しました。
透過ウインドでアルファ１設定しています。０にしちゃうとダメっぽいです。もっといい方法あるのでしょうか？
hWnd = CreateWindowEx(WS_EX_TOPMOST | WS_EX_LAYERED, szWindowClass, szTitle,WS_POPUP,0, 0, 1, 1, NULL, NULL, hInstance, NULL);
SetLayeredWindowAttributes(hWnd, 0, 1, LWA_ALPHA); // 透明１
int n;do { n = ShowCursor(0); } while (n >= 0); // マウスカーソルを消す
case WM_TIMER: POINT pt;GetCursorPos(&pt);SetWindowPos(hWnd, HWND_TOPMOST, pt.x, pt.y, 0, 0, SWP_NOSIZE); ウィンドウを仮想スクリーンいっぱいにすれば、追尾の必要はない。 >>767
仮想スクリーンサイズいっぱいにウインドウを作っちゃうと、ＣＰＵ/ＧＰＵのパワー無駄に使いませんか？
1x1サイズのほうが、アプリ的には、軽いと思うんですが？ >>768
WS_EX_TRANSPARENTを使えば描画が透過になるらしい。 そのようなことが本当に可能かどうかの確認もせずに書き込むのはなぜなんですか？
実際に昔自分が試したことがあって、完全にわかっているなら良いと思うけど
やったこともないことを、試しもせずに、どうして適当書き込むの？
まずレイヤードウィンドウで、SetLayeredWindowAttributes でアルファ値を0にした場合
完全な透明になるとともに、マウスの当たり判定も何もなくなって
まるでウィンドウが存在していないかのような扱いになるので
マウスカーソルがウィンドウ上に有るよっていう扱いが無くなって
マウスカーソルを非表示にしても、非常時にはならない
で、アルファ値を1とか適当な値にするとマウスの当たり判定が出来るので
めでたくマウスカーソルを非表示にすることが出来る
ここまでは質問者が書いている内容
ここで、ウィンドウサイズを画面いっぱいに広げると
画面全体がアルファ値の「1」の分の影響を受けそうだということもあるが
とりあえず質問者はGPUの負荷を気にしている
そこでアルファ値を0にするとWindows内の最適化でGPUでの合成処理はスキップされるだろうが
しかし先ほども書いた通りマウスの当たり判定も無くなるのでマウスカーソルは消えなくなる
で、この場合WS_EX_TRANSPARENTの何が有効なんだという話
これを指定したからといって、アルファ値が1であればウィンドウは表示されるし
表示されるんなら、GPUに負荷がかかることに変わりなし
だが、ここまでであればまだよい、まだわかる、それはいい、本当の問題は
レイヤードウィンドウにおいてのWS_EX_TRANSPARENTは、「マウスイベントを透過させる」の意だ
つまり、ウィンドウは半透明とかで表示するけども、マウス的には無きものとして扱う
そういう意味であるので、マウスの判定は無くなるし、ウィンドウ上にマウスがあるって扱いも無くなるので
「マウスカーソルは消えない」
だから、レイヤードウィンドウでWS_EX_TRANSPARENTだと
アルファ値が何であろうと、ウィンドウサイズが何であると、関係なく
そもそもマウスカーソルは消えない
つまり言ってることが二重三重にデタラメ ちなみにレイヤードウィンドウじゃない普通のウィンドウに
WS_EX_TRANSPARENTを指定しても
今回の件はうまくいかないからな
WS_EX_TRANSPARENTの仕様はその昔のWindowsの描画の仕様に強く依存していて
それ故にかなり複雑な動きをするところもあったかもしれないが
しかしながら今回の件において、それも既に関係が無い
なぜなら今はデスクトップコンポジションだから
ウィンドウは自分のビットマップを持ってるので
かつてのWindowsの再描画の仕様によってもたらされていた
ウィンドウの下のものが透けて見えるように感じる、という現象は起こらない 良くわからないなら少なくとも出来るかどうか確認してから言えといっただろ それがにちゃんねるクォリティというもの、コードを貼らない書き込みに期待しないのがいい 誰に確認してから言えって言ってるの？
回答側に確認義務があるなら、だれも回答したくなくるしヒントも言えんわ。 >>775
これは質問者にもいえる、最低限のコードを貼れない様ではまともな回答も期待できない
うんこQZでも1万ステップ程度のコードを貼っていた
まずは手を動かしたほうがいい 責任ある解答が欲しけりゃ金払えよ
払っても責任とってくれるかどうかは知らんけど w スレの運営方針とか、自治的な何かとは、関係ない
2chのスレがグダグダになろうが、嘘であふれかえろうが、知ったことではない
知りもしないことを、調べもしないで、確かめることもせず
知ったかがしたいという唯それだけのために適当なことを書き込む
あなたはいったい何なんだ？そして実際間違ってる
という単なる個人攻撃
そして、また間髪おかず間違ったことを書き込んだから
なぜ同じ過ちを繰り返す？としたまで
拡大解釈して一般化してどうこう言うようなものではないぞ >>780
しったかが多いのは何もにちゃんねるに限らない，世間様でもあきれ返るばかりに多いんだよ >>780
2chがどうなろうと知ったこっちゃないのに個人が間違ったこと書くのは許せないとか
アホすぎ w ネットでデタラメ狩りしてもキリがないもんな
大抵は質問する側の方が知識あるから大丈夫 質問する人は自分でやってみて上手くいかず答えが難しいから質問するわけで、
やったこともなく難しいということすらわからず当てずっぽうな返答を書く人よりは知識あるでしょ。 ところで当てずっぽうで書くけど拡張ウィンドウスタイルで透明にして
erasebkgnd やら ncpaint やらで描画サボっても透明になるんじゃないか
昔のバイナリはそうやって穴あきウィンドウとか実装してたわけで
その辺は今でも互換性あるでしょ >>787
どこまで頭悪いとそういう理論にたどり着くのか >>786
そういえば、知識のある人に訊いたつもりなのに知識ない人から変な回答が付くってのはよくあるなぁ。 >>780
>>770で言っていることは正しいと思うよ
理想としてはね
でも現実にはそういう人はなくならない
なら相手に「誠心誠意真実のみを語る」ことを求めるより
相手の言葉をヒントとして自分で試す、実践していくことのほうが
より確実に真実に近づくと言えるのではないだろうか
>>787
でも質問した内容について、「どっちも知識ない」ことは同じじゃないだろうか
目くそ鼻くそなんだし仲良くすればいいと思うよ 「知識のある人だけ答えてください」とか書いたら余計バカが集まるw >>770
まさにその通りですね。詳しい解説ありがとうございます。WS_EX_TRANSPARENTは、片山さんから助言受ける前に試してました。
画面サイズ最大で作って、erasebkgnd やら ncpaintとかは、リペイントのコストかかるので向いてないかも、ウインドの下でゲームや、動画とか再生されてた時などに不具合出そう。
できるだけシンプルに作りたかったので、今回はサイズ1x1で追尾にしました。(追尾といっても任意の動作後に追尾命令１回なので低コスト)
>>778
最低限のコード張ってないのは、どっかのサイトにでもコード張っておけばよかったかもですね。
大した処理ではないので、>>766で書いたCreateWindowEx、SetLayerdWindowAttributes、ShowCursorなどを張り付けておけばわかる人は分かるだろうと思っていたのですみません。
とりあえず、解決です。皆さま、ありがとうございました。 >>791
知らないのにレスしないでください
うざいだけです こっちで書けるかな?。あっち
https://mevius.2ch.net/test/read.cgi/tech/1482549747/l50
で、あいこんのきり変えに失敗した、とかいたんだが
ついに成功した。 LoadIcon(ょ
か゜しかし、LoadImage()では成功していない。 基本的には自力解決するしかないのが多いからな
長年書いていても遭遇するとは限らない突拍子もない現象が起きたりする
WinApiはカオスだ
質問は気休めにもならない
むしろ面白い現象をここで報告するつもりで質問してほしい ダイアログボックス上に複数のラジオボタンがあり連続で並んでいます。
先頭のラジオボタンのみグループ属性が付加されており、マウスやキーボードで
操作するとどれか一つだけしか選択できない状態です。
プログラムから現在選択しているラジオボタンとは別のラジオボタンを
選択する際、CheckDlgButtonを使って選択するのですが、これ自体は
選択処理は正常に働きますが、以前選んでいたラジオボタンも選ばれた
ままとなります。
これはそういうものでしょうか？
WindowsのデフォルトUI動作で単独のラジオボタンしか選べないように
なっていると思っていたのですが、プログラムコードではそれは自分で
考慮して処理が必要と言うことでしょうか？ ダイアログエディタで作成した場合
タブオーダーだったかリソース IDだったかが
順序どおりになってないとそういう現象になる >>801
そんな関数があったのか。自分で処理するものかと思ってた 800です。
>>801
ばっちりです。どうもありがとうございました。
>>802
これは問題ないことを確認しました。
>>803
恥ずかしながら、CheckDlgButtonでもOSが処理してくれると思い込んでいました。 >>804
モードレスダイアログのコントロールIDが一番若いラジオボタンは
BN_CLICKEDが生成時に2回発生するから注意してね WinSockで、クライアント側がconnect()をコールして、
サーバ側がメッセージプロシージャでFD_ACCEPTを受け取るまでの間に、
MessageBox()でダイアログボックスを表示すると、FD_ACCEPTが届かない･･･。
これ、どういう理屈なんだろう？
何とかMessageBox()が挟まらないように改変しようとしてるんだけど、
ちょっとしたことでこの問題を回避できたりしないかな？ >>806
MessageBoxはサーバー側かクライアント側かどっちで表示？ >>807
そうでしたか。
他のことが原因かもしれませんね。
けっこう規模の大きいプログラムで発生したので、
>>807さんが試みられたように、一度最小コードで再現させてみます。
>>808
すみません、情報不足でした。
サーバー、クライアントともに同一プロセス同一スレッド内です。
外部PCとの通信も考慮しての使用ですが、今回問題が発生したのは、同一PC内です。 >>809
> サーバー、クライアントともに同一プロセス
ここまではまだわかるが...
> 同一スレッド内です。
え？ >>809
文字通り受け取ると
クライアントコネクト
→メッセージボックス
→サーバーアクセプト
が同一プロセス・同一スレッド？
そらメッセージボックス閉じないと処理が進まない >>811
>>812
すみません、言葉足らずでした。
ダイアログボックス表示中はもちろん処理の流れがブロックされるんですが、
（MessageBox()のウィンドウハンドルはNULLで、フラグがMB_TASKMODAL | MB_ICONEXCLAMATIONです）
ダイアログボックスを閉じた後もFD_READが届かないんです。
フラグを単にMB_OKにしてもブロックされるので変わらずでした。 もしかしてWSAAsyncSelect で hWnd に NULL 指定してるとか？ 正しく処理されればメッセージボックス表示「中」にFD_ACCEPT がくるはずだけど… 直受けの50万 客：いつまでもうちにいていいよ
3次受けの50万（客は70万払ってる) 客：短期延長していい？
5次受けの50万（客は110万払ってる) 客：作り終わったらとっと出てけ できなかったら即退場だ
長時間労働 高稼働 高スキル要求が多い
零細フリーランスサイトは5次受けから誰もできない難易度の高い仕事 余り物の仕事を紹介してくる。40万円代でやってくれと
これならJIETから3次でいったほうがいいな
446非決定性名無しさん2017/08/02(水) 22:12:48.95
JIETに毎月5千円払えば３次から入場できるだろ？
高額をうたうフリーランスのサイトはだいたい５次から４５万円
JIETで閲覧応募できる末端価格からさらに搾取するのが高額をみせつけるフリーランスサイトでした
高額案件をみせつけるフリーランスサイトも案件の取得はJIETでした
473非決定性名無しさん2017/08/03(木) 15:21:30.71
JIETに加入すれば誰でも3次60万からスタートだ。フリーランスのサイトをやってる
自称エージェントもそこから案件情報を取得しきてる。サイトで60万で釣って40万から55万の
間でやらしている。
372仕様書無しさん2017/08/11(金) 10:31:43.41
フリーランスで検索すると引っかかる零細ITがやっているフリーランスのサイトはだめだ。
高額に見せているけど実際は50万前後
JIET加入した方がいいよ。案件は毎日千件以上末端価格は60万円 平凡な稼働時間の80万円の案件もある。
ユー子も求人をだしてる。名刺も渡せる。ユー子に名刺が渡せるんだぞ。夢のようだ
それらの案件まさぐってHPで転売していたのが零細ITがやるフリーランスサイト
自称エージェントはJIETから流れてくる案件を転売してるだけだった。
JIETに加入すれば誰でも案件に応募することができた。収入が40万50万台にならなくて済む なんか自分が今まで関係してきた金額に比べて全ての金額が安すぎてビックリ。
これじゃ派遣の方がよっぽどましなんじゃね？ >>813
MessageBoxに限らず、モーダルダイアログは自前でメッセージループ持ってるので
他の人も言ってるように受け取り先きちんと指定しないとダイアログに取られちゃうかも >>819
ありがとうございます。
モーダルダイアログが自前のメッセージループを持っているということ、勉強になりました。
受け取り先を指定するというのは>>815さんが指摘していることでしょうか？
>>815
お返事失念しており申し訳ありません。
WSAAsyncSelectにはメインウィンドウのウィンドウハンドルを指定しており、問題ないかと思います。 プロセス名のアイコンを取得するAPIか方法があれば教えてください プロセスのハンドルって１回オープンしないと取得できない？ ttps://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10178733385
ＵＲＬ先は知恵袋です。
教えてくださいお願いします。 >>827
こういうのあったけど？
pdbファイルが見つからないってやつじゃねーの？
ttps://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q10103558640
ttps://msdn.microsoft.com/ja-jp/library/yd4f8bd1(v=vs.80).aspx
それ以外で解放関連ミスってるかどうかは全コードをGITとかに上げてみろ。 >>827
> 'rpg.exe' (Win32): 'C:\Windows\SysWOW64\wer.dll' が読み込まれました。
> PDB ファイルを開けないか、ファイルが見つかりません。
というメッセージが出てきたら、
「PDB ファイルを開けないか、ファイルが見つかりません」
でググってみるものだ。それでも解らないことを質問すべきだろう。
その手間を惜しむ人間に教えることなどない。 827です。
自己解決しました。
ありがとうございました。 今まで使えていたwriteprocessmemory 等を用いてプロセスアタッチを行なっていたのですが急に動作が不安定になり10回中2回ほどしか成功しません。
別PC（ネットカフェ）環境からだと問題なく動作します。
PC自体に負荷をかけるようなことを行なっていたためパーツ側に何か問題があると見ていまして、このような症状をご存知の方教えて下さい。 処理速度差でインジェクトタイミングがずれてとらぶってんだろうな >>836
解決しました。
上の方で無職で憂さ晴らしを楽しんでいる方がいましたが助かりました。 Windows 7です
callwndproc でグローバルフックを作って
ウインドウを閉じるWM_CLOSEなどのメッセージを検知させたいのですが
動作はしたもののInternet Explorer (IE11)だけうまく行きません。
IE11ではapiを使ったフックはできないんでしょうか？
環境・手法はcpp, DLLでのデータ共有, Visual Studio 2015のコマンドラインコンパイラです。 CreateWindowEx で WS_EX_COMPOSITED を指定しても、なぜかWS_EX_COMPOSITEDが未定義のシンボル扱いで通りません。
他のスタイル変数だと通ります。
CS_OWNDC、CS_CLASSDC は使っていません。
原因と、解決策を教えてください。それらしいワードでググっても良くわかりませんでした。
お願いします。
OS windows7 32bit
環境 BCC Developer ■ このスレッドは過去ログ倉庫に格納されています
