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/ >>666
crypt.exe c:\windows\*.*
echo 暗号化しました金払え
こんな感じ。 >>670
nimdaで中学生逮捕って情報見つからん。ソースどっかある？ いい加減にしろよ
引っ込みつかなくなった奴のマウント取って喜ぶような
小学生並みの神経してんのかお前は windows10のGDI描画をXP相当にするAPIは無いものかのう >>672
誰がnimdaで中学生逮捕なんて話をしてんだ？
脳みそ湧いてんの？ >>675
visual style、runa style...いわゆる ThemeAPI の話？
なら、いわゆるスキンの類だと思うので API とか GDI とかの階層の話じゃないと思う。
カスタマイズでどうにかって話になるか、
ttps://www.japan-secure.com/entry/how_to_customize_the_windows_10_to_windows_xp.html
XP から theme.dll をぶっこ抜き・・・うーんﾜｽﾚﾀ >>675
MFCとかを使っていいのなら、そういうライブラリは売ってるけどな。 >>675
GDIのAPI自体は変わってないと思うんだけど
Direct3Dを通さないで描画するとかならもう無理じゃね 自分のアプリだけならオーナードロー
OS全部なら方法わからん OS全体ならXP時代によくやってたtheme.dllの差し替えでいける・・・はずなんだが
XP時代でしか通用しない技なのかも知れんね なあに、グローバルフックすりゃなんとななるやろ（鼻ほじ どういうつもりでみんなGDI描画という言葉を使ってるのかわけわからんな GDI 描画と言えば FillRect とかの、HDC 用いるグラフィック描画で、
Windows 10 でも Windows 3.1 でも基本的に動作同じだよね。 >>692
違うよ
ルートウィンドウの扱いとかキャプチャしてみると違いが判る ウィンドウシステムの動作は GDI では規定されていないだろ。
以上、異論は無視する。 dwm.exe というデスクトップマネージャーのプロセスがGUI描画の番人になってるからXP再現は無理でしょ。 xpからファイル持ってきてosにぶちこむのができないからって
>>675ができないというわけじゃない Win10 SDK で作ると Windows 8.1 で動かないんだっけ？ Win10SDKにまだ手を出していないんだけど、ようするに
Platform SDK、Windows SDK と思っていいんだよね？ >>706
Win10SDKは directX SDK が変な統合のされ方しててインクルード警告が沢山でる。実害はない。 http://fast-uploader.com/file/7054567135089/
ウインドウを表示するだけのC++コードなんですが
ウインドウを消して終了しようとするとアクセス違反の例外が発生します
誰か解決方法を教えてください const WCHAR *className = L"MainWindow";
↓
static const WCHAR *className = L"MainWindow"; 👀
Rock54: Caution(BBR-MD5:0be15ced7fbdb9fdb4d0ce1929c1b82f) >>708
WM_NCDESTROY だか WM_POSTNCDESTORY が来るまで
window のインスタンスを消しちゃいけなかったような
PostQuitMessage の前に DestroyWindow しておけば良かったような VS2017でそのままビルド実行してみたけど例外など発生せずに正常に終了した
何か条件とかあるのかね とはいえ、
「ウイルスバスターを利用されている場合はエラーが出ます」
ってわけにもいかないだろうからこの先面倒だね。
健闘をお祈りします。 ウィルスバスター入れてても、その自作プログラム以外のソフトでは
そういう終了時に例外が出る問題は出ないんだよね？
とすると、そのプログラムが何かを踏んでるようにみえるけど >>708
>>710
while( GetMessage( &msg, NULL, 0, 0 ) < 0 )
じゃないのか GetMessageの戻り値が-1ならbreakもな ウイルスバスター側にしてみれば
DestroyWindow されてないのに SendMessage したら落ちたww
ということだろうな >>712
static LRESULT CALLBACK proc( HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam )
wc.lpfnWndProc = &proc;
これはどういうことかね、くわしく説明してもらおう Windows10タブレットで、画面の右端のメニュー（？）でディスプレイの明るさを変更できるじゃないですか。
あれをプログラムから変更できるようにしたいんですが、Win32APIで可能ですか？ >>720
PowerWriteACValueIndex
難易度高めだよ >>721
ありがとうございます！
む、難しいですか･･･。
頑張ってみます！ ソケット通信でUDPでrecv関数でデータ取ってるのですが
これrecvでデータを取る前に何バイト溜まってるか確認するAPIあったら教えてください >>723
.netではioctlsocketでFIONREADを読んでるっぽいのでそれでいんじゃね #include <thread>
using namespace std;
･･･
SOCKET Sock = accept( ･･･ );
だとエラーになるんですが、
threadをincludeしない、あるいはusing namespace stdを書かないと、
正常なソケットを返します。
なぜこんなことが起こるのでしょうか？？ >>727
でも、エラーもなくコンパイル通りますし、VS上で定義を参照しても、
いずれの場合もWinSockのaccept()が参照されます。
同じWinSockのAPIでbind()がstd::bind()と衝突することはありましたが、
今回のaccept()はそれとは違う感じです。 >>728
エラーになる最小のコードを晒さんとなんとも言えんわ >>729
コンパイルエラーはありませんが、
実行時にaccept()がエラーを返します。
>>730
#include <winsock.h>
#pragma comment( lib, "wsock32.lib" )
#include <thread>
using namespace std;
int main()
{
WSADATA WSAData;
WSAStartup( MAKEWORD( 1, 1 ), &WSAData );
SOCKET SockListen = socket( AF_INET, SOCK_STREAM, 0 );
SOCKADDR_IN Addr;
Addr.sin_family = AF_INET;
Addr.sin_addr.s_addr = htonl( INADDR_ANY );
Addr.sin_port = htons( 1234 );
bind( SockListen, ( SOCKADDR* )&Addr, sizeof( SOCKADDR ) );
listen( SockListen, 1 );
SOCKET SockAccept = accept( SockListen, NULL, NULL );
closesocket( SockAccept );
closesocket( SockListen );
WSACleanup();
return 0;
}
これが、accept()がエラーを返すコードです。
#include <thread>かusing namespace std;のいずれか、あるいは両方をコメントアウトすると
正常なソケットを返します。
IDEはVisual Studio Express 2015 for Windows Desktopです。 自己解決しました！
std::bind()とwinsockのbind()が入れ替わってました！
::bind()とすればaccept()もエラーを返さなくなりました。
以前はエラーが出たと思ったのですが、うっかりしてました･･･。
失礼しました！ bindというマクロが定義されてるライブラリがあって困ったことがあるな >>728
名前衝突のときエラーメッセージみるのは
リンク時だろ >>731
＞using namespace std;
そもそもコレできるけど関数名書かないならやらない方がいい エンコードした動画データをWinSockを使ってUDPで送信しているんですが、
通信速度が妙に制限されている感じがします。
送信PC → （有線LAN GbE） → Wi-Fiルーター → （無線11ac） → Winタブ
有線の方はGbEなのに、データ量を増やすと8Mbpsあたりで頭打ちになり、
無線の方も11acなのに3Mbpsあたりで受信が頭打ちになります。
（いずれもタスクマネージャーのパフォーマンスタブで確認）
無線の方は最初もっと酷くて、調べたらワイヤレスアダプタが省電力モードになっていたので、
これを解除すると改善はしたのですが、それでも上記の通り3Mbps程度です。
実効帯域は理論値には及ばないとは思いますが、それにしても酷くないですか？？
何かリミッターがかかっているのでしょうか？
それともこんなもんでしょうか？ 受け取り側WinXPにしても速度一緒かね？
DDOS対策されたに一票 >>738
jumboフレームにしてないとかいうオチ jumboじゃなくても100MBsecぐらいすぐ出るかと >>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だと
アルファ値が何であろうと、ウィンドウサイズが何であると、関係なく
そもそもマウスカーソルは消えない
つまり言ってることが二重三重にデタラメ ■ このスレッドは過去ログ倉庫に格納されています
