Win32API質問箱 Build124

**デフォルトの名無しさん** · 2017/11/11(土) 19:23:00.69

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/

**デフォルトの名無しさん** · 2018/08/31(金) 18:32:30.98

>>607
良さげですね！試してみます。ありがとうございます。

**608** · 2018/08/31(金) 20:11:53.40

どのタイミングでStreachBltを呼び出してるのかわからない…
ウィンドウを制御するクラスの中のWM_PAINTは空だし。
初期化時にDirectXのAPIにhWndを渡してるので勝手にDirectX内部で呼び出してるのかな？
リサイズされた時にhWndを元にHDC作ってそこでStreachBltとか。その後HDC破棄みたいな。
そうなると手出しできないってこと？

**デフォルトの名無しさん** · 2018/08/31(金) 20:17:23.84

それともウィンドウ作成時のスタイル設定などで
リサイズに合わせてスケーリングをどうするのかみたいな設定があるのかな。
それだとそこの設定でどうにかなりそうな気もするけどよく分からない。
ちなみにウィンドウ制御クラスの中のWM_PAINTでは動画などのスケーリングは自前でやってた。
なので少なくともWM_PAINTの中では自分でウィンドウ内部の他の表示のスケーリングはやってない。

**デフォルトの名無しさん** · 2018/08/31(金) 20:46:55.45

ここ見たらたぶん同じような症状で困ってた人がいて
http://dxlib.o.oo7.jp/cgi/patiobbs/patio.cgi?mode=past&;no=1506
基本的に手出しができず綺麗に拡大されるかはドライバによるという事らしい…

え～やだやだ～納得できない。やっすいPCでも綺麗に拡大されてるのに
家の高いPC(ドライバも新しい)で汚いなんて納得できないよ～！

**デフォルトの名無しさん** · 2018/08/31(金) 21:07:44.36

> 現状ではコーラさんがお書き込みになられた方法しかありません
あるって書いてあるじゃｎ

**デフォルトの名無しさん** · 2018/08/31(金) 21:22:40.36

>>612
うん。そうだけど、たっかいグラボ積んでる家のマシンで汚く表示されて
やっすい3万くらいのPCで綺麗に表示されるのが納得いかないの。

**デフォルトの名無しさん** · 2018/08/31(金) 21:23:46.62

>>612
あ、ごめん見間違った。
方法はあるんだけどバッファの大きさは固定でやりたいの。

**デフォルトの名無しさん** · 2018/08/31(金) 21:31:04.55

だからバッファ固定でできるって

**デフォルトの名無しさん** · 2018/08/31(金) 21:32:44.33

なんか意味不明な質問だなと思ったら、それWin32じゃなくてDXライブラリとかいう
よくわからんライブラリの話やん。

**デフォルトの名無しさん** · 2018/08/31(金) 21:33:51.55

拡大した時に粗くなる→最初から内部のバッファの解像度を上げておけばよくね？
ってのはナシで。
あくまでも内部のバッファの大きさは今のままでウィンドウが拡大された時に
勝手にドライバがやる部分をどうにかしたい。けど無理そうだね…

納得いかないのは、やっすいPCでは綺麗に表示されてるのに
たっかいPCで汚く表示されてしまうこと… 逆なら納得したのにこれはないよな～

**デフォルトの名無しさん** · 2018/08/31(金) 21:35:25.97

>>616
いやDXライブラリでも制御できない部分なので
Win32APIの方でなんとかならないのかなと思って。でも無理なのかな。
ここの人ならなんか解決法わかるかなと思ってたけど。

**デフォルトの名無しさん** · 2018/08/31(金) 21:44:49.09

win32でやるならSetStretchBltMode
おまえがやるべきなのは小さい画面サイズのでいいからそのDCを取り出すこと
それしたらあとは表示するだけ

**デフォルトの名無しさん** · 2018/08/31(金) 21:50:44.31

>>619
要するにそれは内部バッファのHDCを取り出して
SetStretchBltModeを設定し、その後ウィンドウのクライアント領域に自前で
StretchBltで描画しろってことになるかな？まあそれしかないのかやっぱ。

**デフォルトの名無しさん** · 2018/08/31(金) 22:41:05.39

さすがに自前でやったらGDI+使っても速度が全然でなかった(毎フレーム描画しないといけないので)。
諦めます～

**デフォルトの名無しさん** · 2018/08/31(金) 22:47:15.40

なんか基本的な部分から盛大に勘違いしてそうだな

Direct3D使ってるならドライバ依存になるのはスワップチェインのバックバッファが
ターゲットウィンドウのサイズとかみ合わない場合に
Presentの呼び出しでウィンドウにフィットするように自動でスケーリングされる部分だ

ドライバ依存の挙動を回避したいならバックバッファをウィンドウに合わせてリサイズするのは必須なの

逆に、バックバッファの解像度をゲームの解像度と考える必要も無い

バックバッファがどんなサイズであれゲーム自体は固定サイズのレンダーターゲット用テクスチャにレンダリングし
バックバッファへはそのテクスチャをスプライトとして張り付けるだけ
拡縮フィルタリングをニアレストにするのもバイリニアにするのもアプリでしっかり管理できる
なんならシェーダでLanczosにしても良い

**デフォルトの名無しさん** · 2018/08/31(金) 23:02:05.30

せっかく諦めたのに

**デフォルトの名無しさん** · 2018/08/31(金) 23:19:59.47

>>622
なるほど～バッファをリサイズしないと必ずドライバ依存のスケーリングになってしまうってことね。
その辺りをもうちょい考えてどう対処するか検討してみるよ。ありがとう。
>>623
まだまだ諦めんぜえ～ｗｗ

**デフォルトの名無しさん** · 2018/08/31(金) 23:25:09.45

野菜の日

**デフォルトの名無しさん** · 2018/09/04(火) 23:00:53.53

CreateFile()で取得したハンドルをGetMailslotInfo()に渡していいものでしょうか？
CreateFile()の第1引数には、別プロセスでCreateMailslot()したときの第1引数と同じ
です。

**デフォルトの名無しさん** · 2018/09/05(水) 08:35:25.55

流石にmsdn見ろとしか

**デフォルトの名無しさん** · 2018/10/03(水) 18:23:25.15

リストビューでマウスドラッグで範囲選択をしているとき、
その選択範囲の矩形座標を取得する仕組みは無いのでしょうか。
範囲選択開始時のLVN_MARQUEEBEGINしか見つからないのですが。

**デフォルトの名無しさん** · 2018/10/05(金) 23:00:23.19

メインウィンドウのメッセージループからマウス系イベント拾ってくるのが楽で良い

**デフォルトの名無しさん** · 2018/10/18(木) 16:38:48.09

AVIStreamGetFrameOpenというAPIで「MPEG-4 Visual (XviD)」で
圧縮されたaviファイルを開きたいのですが可能でしょうか？
また上記が無理なら無圧縮以外の何かでエンコードされたものを
開きたいのですが何だったら可能なのかも教えてもらえないでしょうか？
AVIStreamGetFrameOpenは、2番目の引数にAVIGETFRAMEF_BESTDISPLAYFMTを指定すれば
完全な無圧縮以外でYUY2だけはいけました。

**630** · 2018/10/18(木) 17:40:26.75

調べていたらコーデックというのはAVIStreamGetFrameOpenで使用されたような古い形式と
メディアプレイヤーで使用されてるような新しい形式があるようですね…
つまりこの古いAPIだとそれように提供されているコーデックを探してインストールしないといけないという事になるでしょうか？
新しい形式を利用するプログラムを作った方がいいような気がしてきました。

**630** · 2018/10/18(木) 18:23:13.79

確かにVideo for Windows用のコーデックを探してきてインストールすれば動くようになりました。
解決はしたのですが他のPCでもその都度これをインストールしないといけないってのがどうも…

**デフォルトの名無しさん** · 2018/10/18(木) 18:34:46.06

そりゃコーデックのインストールは必須だよ
自前実装するとかなら別だけど

**デフォルトの名無しさん** · 2018/10/18(木) 18:57:16.36

>>633
ただ新しいタイプの方(DirectShow)の方はメディアプレイヤーとかも入ってるので
デフォルトでも結構動きそうなのでそこがいいなと。
初回のプログラム起動時にコーデック用dllだけシステムフォルダに突っ込んでもいいのかな…

**デフォルトの名無しさん** · 2018/10/19(金) 12:08:49.41

>>632
ffmpeg

**デフォルトの名無しさん** · 2018/10/19(金) 17:30:46.21

ところでMacとかだと64bit化で32bit打ち切りの方向みたいだけど、Winはまだまだ32bitもサポートしてくれるよね？

**デフォルトの名無しさん** · 2018/10/19(金) 19:13:40.82

今のって64bit環境でエミュレーションしてるんだっけ？だから基本的にはずっと維持されるのかな？

**デフォルトの名無しさん** · 2018/10/20(土) 11:06:47.52

WOW64だけ終了させるのは考えにくいね。
32bit過去資産を切り捨てるメリットが当面無い。

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

Macはそんな環境で動いているケースはほとんどないから問題ない気がする。

◆QZaw55cn4c · 2018/10/20(土) 11:46:35.45

>>638
＞128bitOS
128ビットアーキテクチャーとか 128ビットOS とかは、ここ30年くらいは現れないのではないでしょうか…

**デフォルトの名無しさん** · 2018/10/20(土) 11:57:36.98

8/16bit全盛時代、64bitを現実的に捉えてた人は居なかったしなあ。
128bitなんて遠い先だと今は思ってても、どうなるか分からんもんよ。

**デフォルトの名無しさん** · 2018/10/20(土) 12:18:25.97

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

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

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

こうか？

**デフォルトの名無しさん** · 2018/10/20(土) 12:22:46.95

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

こうなる可能性も悪夢

**デフォルトの名無しさん** · 2018/10/20(土) 13:36:52.57

>>640
8/16bit全盛時代は32bitデスクトップコンピューターが
スーパーパソコンと言われることもあったなあ

32bit機なんて夢だった、64bit機なんて遠い未来に
実現するのかなあという感覚

**デフォルトの名無しさん** · 2018/10/20(土) 19:16:09.86

>>638
そういうところがOSだけ最新なの使っているものなのか？
古いアプリケーションをずっと使っているようなところだとOSも昔のままな気がするけど

>>641
その時にはSYSTEM32って名称はやめていると思う
んで、64bit以前のアプリケーション互換云々は単純に仮想マシン環境下で動作させればいい
仮想マシン上でも十分な性能を得られるだろうし

**デフォルトの名無しさん** · 2018/10/20(土) 19:42:10.64

128bitは多分こないんじゃないかなｗ
32bitとか64bitってメモリマッピングの領域の問題なんで
64bitなら4GByte×4GByteまでマッピング出来てしまうので
超絶高速SSDとかできてONメモリのように管理できるように
なっても64bit超えないような

**デフォルトの名無しさん** · 2018/10/20(土) 20:09:53.22

ドリームキャストは128bitって連呼してたなぁ

**デフォルトの名無しさん** · 2018/10/20(土) 20:18:05.59

既にWindowsフォルダ配下はカオスだろ
M$よくこんなん管理できんなーと思ってたらやっぱり管理できてなかったみたいだな

**デフォルトの名無しさん** · 2018/10/20(土) 21:00:21.96

アプリケーション的には
16bits → 64KB 死ぬほど不便
32bits → 4GB 快適
64bits → 16EB 贅沢できる

**デフォルトの名無しさん** · 2018/10/21(日) 02:36:06.52

32bitアプリ使ってる人多いだろうから動かなくなったら苦情がめちゃくちゃ来そう。

**デフォルトの名無しさん** · 2018/10/21(日) 03:23:03.53

>>643
でもその頃、汎用機は32bit機械だったよ？
アドレッシングは24bitだったけど。

>>645
AS400は128bitと言ってもいいのでは。
むしろIoTとか言ってコンピュータ側のリーチが伸びてるから
単一レベル記憶で世界を管理しようとしたら、既にある技術で言えば
IPv6は128bitだし、既に128bitの世界はきてる気がするよ。

**デフォルトの名無しさん** · 2018/10/21(日) 05:03:20.85

既存プロセスのウィンドウhwndに対するファイルのドラッグ＆ドロップをマウスエミュレートを使わず実現するにはどうしたらよいですか？
過渡的な視覚効果であるドラッグは必要ないので、実質ドロップだけできればいいとは思うのですが。

**デフォルトの名無しさん** · 2018/10/21(日) 08:15:24.58

>>649
そもそもVisual Studioが32bitだから32bit打ち切ったら開発できなくなるし w

**デフォルトの名無しさん** · 2018/10/21(日) 14:33:56.37

>>650
個人が買えるPCの話だよ、その頃はPCで
32Bitアドレッシング24Bitなんて夢だった

**デフォルトの名無しさん** · 2018/10/21(日) 16:15:03.17

>>653
XL2でも100万だったけど？

**デフォルトの名無しさん** · 2018/10/21(日) 18:55:34.10

> アプリケーション的には
> 16bits → 64KB 死ぬほど不便
> 32bits → 4GB 快適
> 64bits → 16EB 贅沢できる

8bitは ?

◆QZaw55cn4c · 2018/10/21(日) 18:59:32.77

>>655
＞8bitは ?
ほとんどの 8 ビットCPU のアドレス空間はすでに 16 ビットだったからなあ…

**デフォルトの名無しさん** · 2018/10/21(日) 19:06:52.55

マウントの取り合いになってきたゾ～

**デフォルトの名無しさん** · 2018/10/21(日) 20:51:33.47

>>651
アプリケーション毎にドラッグをどう処理しているか不明だからマウスエミュが確実だと思うけど

**デフォルトの名無しさん** · 2018/10/21(日) 21:19:33.66

>>651
ttps://docs.microsoft.com/en-us/windows/desktop/shell/wm-dropfiles

**デフォルトの名無しさん** · 2018/10/21(日) 21:43:12.45

>>655
アドレスが8bitの汎用CPUなんてないんじゃない？
4004でさえアドレスは12bitだそうだ

**651** · 2018/10/22(月) 01:10:30.37

>>659
WM_DROPFILEはすでに試して失敗を確認済みです。
ドラッグ＆ドロップの具体例をあげるとVisual Studio 2017 にファイルをドロップして開く処理をやりたいのだけど、
GlobalAlloc()、GlobalLock()、GlobalUnlock() などで作ったhDropをPostMessage(WM_DROPFILE)しているのだけど、まったく変化なし。
メモ帳notepad.exeの場合はPostMessage(WM_DROPFILE)で開けたのですが、VS2017と何が違うのやら。

**デフォルトの名無しさん** · 2018/10/22(月) 02:10:39.32

WM_DROPFILEの他に、OLE Drag&Dropもあるでよ

**デフォルトの名無しさん** · 2018/10/22(月) 12:32:01.71

PIC のアドレスって何bitだっけ
68xx の memory mapped register とかは 8bit か
そもそもどうでもいい

**デフォルトの名無しさん** · 2018/10/22(月) 14:14:29.65

>>648がネタだったらどうでもいいのだが
16bitのWindows3.1でも 1Mを越えるメモリーは使えたし、
32bitのWindowsのアプリケーションのメモリー空間は32bitではないし
64bitのWindowsのアプリケーションのメモリー空間は64bitではない

**デフォルトの名無しさん** · 2018/10/22(月) 15:48:26.25

アセンブラで書いてるのかω

**デフォルトの名無しさん** · 2018/10/22(月) 18:19:05.88

8bit→16bit　前世代の256倍
16bit→32bit　前世代の65536倍
32bit→64bit　前世代の4294967296倍
64bit→128bit　前世代の18446744073709551616倍
で各時代のジャンプしてる倍数が全然リニアじゃない
128bitは俺らが生きてる間に実現しない

**デフォルトの名無しさん** · 2018/10/22(月) 18:27:51.91

つまりは
8bit倍→16bit倍→32bit倍→64bit倍　とくるから
だんだん間隔が長くなって正常
64bit(前世代の32bit倍)ですら途方もなくて持て余す(実際48bit)のに
64bit倍なんてのは途方もないものはどうしようもない
永遠に到達しないと思っても問題ないくらいに天文学的数値

**デフォルトの名無しさん** · 2018/10/22(月) 18:38:09.95

そうでもない
進化は指数関数的に変化するから

**デフォルトの名無しさん** · 2018/10/22(月) 18:44:02.73

CPU取り扱いビット数は、なにもメモリー空間だけの問題じゃないと思うが。
なんにしても、ないもの語るのは不毛な話だわ。

**デフォルトの名無しさん** · 2018/10/22(月) 19:04:08.99

64bit増毛

**デフォルトの名無しさん** · 2018/10/22(月) 19:06:40.33

CPUのビット数と言ったらやっぱりメモリ空間だろ
俺らに関係する互換性の意味でもさ

>>668
bit数が一つ増えると2倍になるが、そのbit数も2倍で増やしていくから
指数関数の指数関数でとんでもない速度で増加する
一方でムーアの法則はただの指数関数だから
割り算すると指数関数が残る
というのが>>666-667の説明

**デフォルトの名無しさん** · 2018/10/22(月) 22:15:29.36

さすがに64bitアドレスを使い切ることは無いべ？
下手すると64bit個の原子は目で見えるサイズじゃないか？

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

砂粒くらいはありそうだよな？

**デフォルトの名無しさん** · 2018/10/22(月) 22:22:39.79

みんながそう思ったら、IPv6は128bitにしなかっただろうね :-p

**デフォルトの名無しさん** · 2018/10/22(月) 23:05:44.67

過去からbit数が上がる際にはメモリー空間に限定した話ではなくて
「パフォーマンスが上がる」というまずは大ざっぱな喧伝がなされてた
メモリー空間はもちろん広がるが、そんな限定的な事じゃない様々な性能アップ要素で
話がされたもので、今になってメモリー空間だけに絞った話にしかならないのは
その話している人の経験や視野が狭すぎるのが原因ではなかろうか

**デフォルトの名無しさん** · 2018/10/22(月) 23:08:02.77

>>664
アプリケーションの話をしてんだから
8086 死ぬほど不便あってるじゃん

32bitのWindowsのアプリケーションのメモリー空間は32bitじゃん？
36bit使える？32bitアプリが。

**デフォルトの名無しさん** · 2018/10/23(火) 01:54:45.89

>>674
80286とi386だと、クロックが同じだと80286の方が速いこともあったよ？

**デフォルトの名無しさん** · 2018/10/23(火) 02:55:48.42

アーキテクチャや最適化とかあらゆる要素を全く無視して
一部だけ切り取って主題の否定に終始しておけば勝つから頑張れ

**664** · 2018/10/23(火) 10:09:02.12

>>675
Windows3.1は8086では動かない
多くの32bit Windowsアプリケーションのメモリー空間は 2G (31bits)

**デフォルトの名無しさん** · 2018/10/23(火) 11:47:28.84

何でCPUのbit数の話がメモリのサイズ限定になるってそりゃ当たり前ここはプログラム板だから
ポインタのサイズがいくらになるかが互換性の面で最大限問題なんだよ
互換性の面でな

**デフォルトの名無しさん** · 2018/10/23(火) 11:49:19.92

しかもここはWin32APIのスレで
128bitのWinAPIはいつ出るかって話だから
ポインタのサイズ=メモリ空間のサイズの
話になっていくのは当たり前

**デフォルトの名無しさん** · 2018/10/23(火) 12:48:48.94

>>675
128bitマシンがあっても
FDDだったら死ぬほど不便だな

**デフォルトの名無しさん** · 2018/10/23(火) 15:26:03.23

>>681
オンラインストレージもすべてアドレッシングされてるような美来を考えると、
そんなに不便でもないような気も少し。

**デフォルトの名無しさん** · 2018/10/23(火) 15:28:44.02

>>679-680
> 何でCPUのbit数の話がメモリのサイズ限定になるってそりゃ当たり前ここはプログラム板だから

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

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

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

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

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

アドレッシングの話題は話題でやればいいですが、これを論拠に「だから次はない」
なんてのはナンセンスというだけの話です。

**デフォルトの名無しさん** · 2018/10/23(火) 16:08:56.16

レジスタ長やら命令セットの話なら既にAVX512とかがあるでしょ
ただこれとWin32APIは関係ないでしょ？
x64が続く限りWin32APIのサポートがずっとあるのは明白だし
(あえて命令セットを変える意味がないでしょ・・・何の意味が？)
もし変えるとしたら128bit化の時だろうけど
まず生きてる間には来ないよねって話でしょ

**デフォルトの名無しさん** · 2018/10/23(火) 16:18:21.83

ちなみに128bit化に伴って32bitプロセスがサポートされなくなる可能性は有る
何故なら128bitは100年後か1000年後かあるいは永遠に来ないか
そのぐらいの未来になったら32bitプロセスはすっかりレガシーになってて
サポートする意味が無いかもしれん、わからんがな
ただそんな未来は生きてる間に来そうにない、という事で
Win32APIのサポートが無くなることはないだろうという事を述べておる

**デフォルトの名無しさん** · 2018/10/23(火) 17:00:05.35

>生きてる間には来ない

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

空気読めないアスペか？

**デフォルトの名無しさん** · 2018/10/23(火) 17:40:29.64

I/Oがすべてマッピングされている世界はたぶんたのしい

**デフォルトの名無しさん** · 2018/10/23(火) 17:47:11.62

PCIとかはメモリ空間にマッピングされているよね

**デフォルトの名無しさん** · 2018/10/23(火) 17:55:28.41

計算したら来ないし
遠い未来すぎて今と状況が違いすぎるからなんとも

結局は32bitをサポートするかは技術的というより時間的要因とうか周りからの要求で決まるわけで
例えばもし10年後に128bitになるなら32bitをサポートするようにCPUを作るだろうし
100年後だったらもはやレガシーすぎてサポートしないかもだし
(その場合はソフトエミュレーションかな)
結局は問題ないだろうということ
俺らが困らないようにしてくれるさ
IntelがItaniumを作って広げようとしても、AMDがx86作ってそっちが選ばれたしな
互換が無くなって一番困るのは俺らよりマイクロソフトだから何とかしてくれるのだわ

**デフォルトの名無しさん** · 2018/10/23(火) 17:58:27.40

ただ、Windowsが無くなればWin32APIも無くなるが。。。

**デフォルトの名無しさん** · 2018/10/23(火) 18:15:44.57

> レジスタ長やら命令セットの話なら既にAVX512とかがあるでしょ
AVXのときにAVX512なんて絶対来ないとか言ってたか？
次がどうなるとお前が決める事ではない

> ただこれとWin32APIは関係ないでしょ？
関係ないからこそWin32APIだけの話題で次があるないを確定づける論拠にするのに意味がない

**デフォルトの名無しさん** · 2018/10/23(火) 19:35:50.85

ポインタのサイズが互換性において何の問題が？

**デフォルトの名無しさん** · 2018/10/23(火) 20:21:56.29

32/64だとポインタをDWORDに放り込んで処理してるのとかあるからな

**デフォルトの名無しさん** · 2018/10/23(火) 23:44:40.09

window handleとかはx64だと64bit幅だけど、wow64でもそのまま扱えるように32bit内の値しか設定されないとかあるね。

**687** · 2018/10/24(水) 06:38:30.05

>>682が書いているように
I/Oの中身がすべてアドレスでとれるようなマッピングのこと
他のPCもまるごとアドレシングされているような世界

**デフォルトの名無しさん** · 2018/10/24(水) 11:37:09.95

>>692-693
rubyは困りそうω

**デフォルトの名無しさん** · 2018/10/24(水) 13:36:44.56

>>696
perl もだよ。
perlでライブラリWin32APIで構造体をマッピングする場合、
構造体のメンバー変数のアラインメントを自力で解決しなければならず、
32bit版と64bit版でオフセットを適切に切り替えるコードが必要。

◆QZaw55cn4c · 2018/10/25(木) 00:37:44.65

http://wisdom.sakura.ne.jp/system/

**デフォルトの名無しさん** · 2018/10/25(木) 11:37:51.73

えらい古いな
っていうか赤坂玲音って糞筆者の筆頭じゃねーか
QZ って赤坂玲音だったのか？

**デフォルトの名無しさん** · 2018/10/27(土) 13:09:18.62

今や当たり前のようになった入力補完候補の動的羅列を従来のコンボボックスのドロップダウンリストでやってみた。
作成済みコンボボックスは途中でオーナードローにスタイル変更できないので、毎回リストを再構築することにした。
ドロップダウンリストの再構築に時間がかかっているように見えたので、
試しにリストをSetRedraw(FALSE)で描画せずに再構築したところ、まったく時間がかからなくなった。
リストアイテムに追加していく処理のたびに描画で重くなっていただけだった。

結論：
ドロップダウンリストの動的変更はSetRedraw(FALSE)で見かけ上は高速に実行可能。
リスト再構築が終わったらSetRedraw(TRUE)で再び描画できるようにして RedrawWindow() などを呼べばOK。

**デフォルトの名無しさん** · 2018/10/27(土) 13:29:57.46

おめ子

**デフォルトの名無しさん** · 2018/10/28(日) 03:50:14.50

>> 700　SetRedraw スレチ

**700** · 2018/10/28(日) 04:05:03.07

>>702
別にMFCの話したかったわけじゃないんだが。
リスト破棄とアイテム追加のたびに描画処理が行われるとどうしてもアイテム更新完了が遅くなる。
オーナードローできない汎用のリストコントロールのアイテム更新はSetRedraw()つまりSendMessage(WM_SETREDRAW)で描画抑止すれば高速実行できる、というのが主旨。

**デフォルトの名無しさん** · 2018/10/28(日) 15:00:14.25

>>702
Win32API的には SetWindowRedraw (WM_SETREDRAW) でOK

**デフォルトの名無しさん** · 2018/10/28(日) 22:57:05.89

>>691
違うって
AVXだろうがAVX512だろうがAVX1024だろうが
ただの拡張命令だから何がこようがどうでもよいけど
ポインタのサイズだけは命令セット全体に影響して互換性の面で問題が出るから
プログラマとしてそこが真っ先に気になるのは当たり前だろうよ

そんでポインタのサイズが64bitで足りなくなる事は生きてる間には無さそうということと
今現在64bit版のWin32APIのサポートがあることを合わせて考えて
Win32APIのサポートの心配するより自分の寿命の心配したほうが良いってことに
ただし、将来Windowsが無くなったら知らんが

**デフォルトの名無しさん** · 2018/10/28(日) 23:18:58.18

AVXとか持ち出した人自身がどうでもいいとか言い出したよ

**デフォルトの名無しさん** · 2018/10/28(日) 23:34:05.53

すみません
アナルに今電極を差してみているのですが
どのくらいの電圧が人間の限界なのかがよく分かっていません
参考までにお教え願えませんでしょうか？