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/ ついでに質問だけど
win10あたりからウィンドウの枠のちょっと外まで(影なしにしてても)
ウィンドウのリサイズとかマウスアイコン⇔の判定に使われてるみたいで
ウィンドウの下のウィンドウを上にもって来たくてクリックしたつもりが
違うウィンドウが上に来てしまうことが多くて困ってる
これなんとかする設定どこにある？ このスレ的な解決だとFrameRectをフックして少し大きめの枠に変えちゃえばいいのかな > 具体的にはWS_MAXIMIZEBOXが無いとスナップできません。
win7 WS_MAXIMIZEBOXなしのタイトルバーをマウスでつまんで
desktopの上辺に移動してマウスを放すと、
タイトルバーが完全に表示されるように再移動される
これもsnapではないのか >>581
そうですね。即席で調べただけなので見落としてました。
いずれにせよ、スナップ操作時にどういったウィンドウならばどういう作用が起こるのか、
逆に特定のスナップの効果が欲しい場合にどういうウィンドウをセットアップすればよいのか
みたいなことがわかる情報を探しています。 実行中のGUIアプリケーションのコントロールを取得して表示させたいのですが良い方法はありますか？ hwnd検索するだけの質問だったのか
てっきりインジェクトして中身奪い取るとかそんなのかと思ったわｗｗ そっちならAppInit_DLLsの勉強しなされ
ってのが回答かな >>589
素直にわからないって言えよ
>>588の「先」は、「自分のプロセスに貼ったコントロールを、そのまま残しつつさらに別プロセスのウインドウに貼り付けて表示する」ということだからな >>590
なんでそんなことするのか全然わからん。
>そのまま残しつつ
>貼り付けて >>593
飽きれるほどくだらない揚げ足取りだな
「パスワードを奪い取る」の考えてみろ。残さないとは限らないんだよ >>594
飽きれるほど下手な例えだな
パスワードは残さないと使えないだろ パスワードはいただいた
返して欲しければ1BC用意しろ パスワード変えずに「パスワードはいただいた」って？
それ何の脅しにもならんやん
元の持ち主が別のに変更して終わり え？おもしろいとでも思ってたの？
もしかして渾身のギャグなの？
恥ずかしくないの？ 程度が同じじゃないとジョークは通じないらしい
ただ今回はガキとバカだからどちらも等しく低いように見えるな 昔のゲームのコードを弄ってて困った事があります。
ウィンドウの大きさを変えると一緒に表示中の画面も引き延ばされるのですが
引き延ばされた時に粗くなって美しくないです。内部のバッファをウィンドウを最大化された時の大きさで確保しておき
ゲームの処理の方でフィルタ処理を施せば上手く行きますが出来れば小さいバッファのままで
ウィンドウのリサイズ時にAPI側でフィルタ処理できないでしょうか？
あと気になるのが環境によっては上記の処理を勝手にやってくれている環境もあります(ディスプレイドライバによるのかもしれません)。
出来れば確実にこちらで処理できるようになれば嬉しいです。 >>604
普通、WM_SIZEの都度ゲームのフレームバッファを再作成するもんじゃねえの？ >>605
出来ればバッファの大きさは固定で行きたいんです。
最大化された時にいかにも拡大してフィルタリングされた感じを出したいので。
環境によってはウィンドウがリサイズされると勝手にフィルタリングしてくれて
ぼやっとした画面になるので出来ればそれを確実にやりたい感じです。
何か設定でもあるんでしょうか。OSの設定としてあるならそれを知りたいです。 >>607
良さげですね！試してみます。ありがとうございます。 どのタイミングでStreachBltを呼び出してるのかわからない…
ウィンドウを制御するクラスの中のWM_PAINTは空だし。
初期化時にDirectXのAPIにhWndを渡してるので勝手にDirectX内部で呼び出してるのかな？
リサイズされた時にhWndを元にHDC作ってそこでStreachBltとか。その後HDC破棄みたいな。
そうなると手出しできないってこと？ それともウィンドウ作成時のスタイル設定などで
リサイズに合わせてスケーリングをどうするのかみたいな設定があるのかな。
それだとそこの設定でどうにかなりそうな気もするけどよく分からない。
ちなみにウィンドウ制御クラスの中のWM_PAINTでは動画などのスケーリングは自前でやってた。
なので少なくともWM_PAINTの中では自分でウィンドウ内部の他の表示のスケーリングはやってない。 ここ見たらたぶん同じような症状で困ってた人がいて
http://dxlib.o.oo7.jp/cgi/patiobbs/patio.cgi?mode=past&;no=1506
基本的に手出しができず綺麗に拡大されるかはドライバによるという事らしい…
え〜やだやだ〜 納得できない。やっすいPCでも綺麗に拡大されてるのに
家の高いPC(ドライバも新しい)で汚いなんて納得できないよ〜！ > 現状ではコーラさんがお書き込みになられた方法しかありません
あるって書いてあるじゃｎ >>612
うん。そうだけど、たっかいグラボ積んでる家のマシンで汚く表示されて
やっすい3万くらいのPCで綺麗に表示されるのが納得いかないの。 >>612
あ、ごめん見間違った。
方法はあるんだけどバッファの大きさは固定でやりたいの。 なんか意味不明な質問だなと思ったら、それWin32じゃなくてDXライブラリとかいう
よくわからんライブラリの話やん。 拡大した時に粗くなる→最初から内部のバッファの解像度を上げておけばよくね？
ってのはナシで。
あくまでも内部のバッファの大きさは今のままでウィンドウが拡大された時に
勝手にドライバがやる部分をどうにかしたい。けど無理そうだね…
納得いかないのは、やっすいPCでは綺麗に表示されてるのに
たっかいPCで汚く表示されてしまうこと… 逆なら納得したのにこれはないよな〜 >>616
いやDXライブラリでも制御できない部分なので
Win32APIの方でなんとかならないのかなと思って。でも無理なのかな。
ここの人ならなんか解決法わかるかなと思ってたけど。 win32でやるならSetStretchBltMode
おまえがやるべきなのは小さい画面サイズのでいいからそのDCを取り出すこと
それしたらあとは表示するだけ >>619
要するにそれは内部バッファのHDCを取り出して
SetStretchBltModeを設定し、その後ウィンドウのクライアント領域に自前で
StretchBltで描画しろってことになるかな？まあそれしかないのかやっぱ。 さすがに自前でやったらGDI+使っても速度が全然でなかった(毎フレーム描画しないといけないので)。
諦めます〜 なんか基本的な部分から盛大に勘違いしてそうだな
Direct3D使ってるならドライバ依存になるのはスワップチェインのバックバッファが
ターゲットウィンドウのサイズとかみ合わない場合に
Presentの呼び出しでウィンドウにフィットするように自動でスケーリングされる部分だ
ドライバ依存の挙動を回避したいならバックバッファをウィンドウに合わせてリサイズするのは必須なの
逆に、バックバッファの解像度をゲームの解像度と考える必要も無い
バックバッファがどんなサイズであれゲーム自体は固定サイズのレンダーターゲット用テクスチャにレンダリングし
バックバッファへはそのテクスチャをスプライトとして張り付けるだけ
拡縮フィルタリングをニアレストにするのもバイリニアにするのもアプリでしっかり管理できる
なんならシェーダでLanczosにしても良い >>622
なるほど〜バッファをリサイズしないと必ずドライバ依存のスケーリングになってしまうってことね。
その辺りをもうちょい考えてどう対処するか検討してみるよ。ありがとう。
>>623
まだまだ諦めんぜえ〜ｗｗ CreateFile()で取得したハンドルをGetMailslotInfo()に渡していいものでしょうか？
CreateFile()の第1引数には、別プロセスでCreateMailslot()したときの第1引数と同じ
です。 リストビューでマウスドラッグで範囲選択をしているとき、
その選択範囲の矩形座標を取得する仕組みは無いのでしょうか。
範囲選択開始時のLVN_MARQUEEBEGINしか見つからないのですが。 メインウィンドウのメッセージループからマウス系イベント拾ってくるのが楽で良い AVIStreamGetFrameOpenというAPIで「MPEG-4 Visual (XviD)」で
圧縮されたaviファイルを開きたいのですが可能でしょうか？
また上記が無理なら無圧縮以外の何かでエンコードされたものを
開きたいのですが何だったら可能なのかも教えてもらえないでしょうか？
AVIStreamGetFrameOpenは、2番目の引数にAVIGETFRAMEF_BESTDISPLAYFMTを指定すれば
完全な無圧縮以外でYUY2だけはいけました。 調べていたらコーデックというのはAVIStreamGetFrameOpenで使用されたような古い形式と
メディアプレイヤーで使用されてるような新しい形式があるようですね…
つまりこの古いAPIだとそれように提供されているコーデックを探してインストールしないといけないという事になるでしょうか？
新しい形式を利用するプログラムを作った方がいいような気がしてきました。 確かにVideo for Windows用のコーデックを探してきてインストールすれば動くようになりました。
解決はしたのですが他のPCでもその都度これをインストールしないといけないってのがどうも… そりゃコーデックのインストールは必須だよ
自前実装するとかなら別だけど >>633
ただ新しいタイプの方(DirectShow)の方はメディアプレイヤーとかも入ってるので
デフォルトでも結構動きそうなのでそこがいいなと。
初回のプログラム起動時にコーデック用dllだけシステムフォルダに突っ込んでもいいのかな… ところでMacとかだと64bit化で32bit打ち切りの方向みたいだけど、Winはまだまだ32bitもサポートしてくれるよね？ 今のって64bit環境でエミュレーションしてるんだっけ？だから基本的にはずっと維持されるのかな？ WOW64だけ終了させるのは考えにくいね。
32bit過去資産を切り捨てるメリットが当面無い。
32bitって、一般的なアプリだけなら切る方向に動くのもあり得る話だけど、
工業系で周辺ハードウェアを制御するのに32bitドライバとか組み込んでて
不思議じゃないので簡単に切れるレベルじゃないかと。
ARM系なんか採用してたらムリじゃね。
128bitOSが出てきたときにようやく切るようになるんじゃないかな。
Macはそんな環境で動いているケースはほとんどないから問題ない気がする。 >>638
＞128bitOS
128ビットアーキテクチャーとか 128ビットOS とかは、ここ30年くらいは現れないのではないでしょうか… 8/16bit全盛時代、64bitを現実的に捉えてた人は居なかったしなあ。
128bitなんて遠い先だと今は思ってても、どうなるか分からんもんよ。 WOW64←32bit用のフォルダ
SYSTEM32←64bit用のフォルダ
では128bit化したときはどうなる？
WOW64←32bit用のフォルダ
WOW128←64bit用のフォルダ
SYSTEM32←128bit用のフォルダ
こうか？ WOW128←32bit用のフォルダ
WOW64←64bit用のフォルダ
SYSTEM32←128bit用のフォルダ
こうなる可能性も悪夢 >>640
8/16bit全盛時代は32bitデスクトップコンピューターが
スーパーパソコンと言われることもあったなあ
32bit機なんて夢だった、64bit機なんて遠い未来に
実現するのかなあという感覚 >>638
そういうところがOSだけ最新なの使っているものなのか？
古いアプリケーションをずっと使っているようなところだとOSも昔のままな気がするけど
>>641
その時にはSYSTEM32って名称はやめていると思う
んで、64bit以前のアプリケーション互換云々は単純に仮想マシン環境下で動作させればいい
仮想マシン上でも十分な性能を得られるだろうし 128bitは多分こないんじゃないかなｗ
32bitとか64bitってメモリマッピングの領域の問題なんで
64bitなら4GByte×4GByteまでマッピング出来てしまうので
超絶高速SSDとかできてONメモリのように管理できるように
なっても64bit超えないような 既にWindowsフォルダ配下はカオスだろ
M$よくこんなん管理できんなーと思ってたらやっぱり管理できてなかったみたいだな アプリケーション的には
16bits → 64KB 死ぬほど不便
32bits → 4GB 快適
64bits → 16EB 贅沢できる 32bitアプリ使ってる人多いだろうから動かなくなったら苦情がめちゃくちゃ来そう。 >>643
でもその頃、汎用機は32bit機械だったよ？
アドレッシングは24bitだったけど。
>>645
AS400は128bitと言ってもいいのでは。
むしろIoTとか言ってコンピュータ側のリーチが伸びてるから
単一レベル記憶で世界を管理しようとしたら、既にある技術で言えば
IPv6は128bitだし、既に128bitの世界はきてる気がするよ。 既存プロセスのウィンドウ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) ■ このスレッドは過去ログ倉庫に格納されています
