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/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

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

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

>>707
今差しているんだろ？
限界になるまで電圧上げてみればいい

**デフォルトの名無しさん** · 2018/10/29(月) 03:39:30.92

電流か

**デフォルトの名無しさん** · 2018/10/29(月) 11:33:26.98

>Win32APIのサポートの心配するより自分の寿命の心配したほうが良い

どっちも心配

◆QZaw55cn4c · 2018/10/29(月) 19:36:35.79

>>699
＞赤坂玲音って糞筆者の筆頭
kwsk

**デフォルトの名無しさん** · 2018/10/29(月) 23:04:33.26

何かプリキュアとか好きそうなイメージ

**デフォルトの名無しさん** · 2018/10/30(火) 14:43:24.71

橋本和明
山本洋介山
こいつらよりまし

**デフォルトの名無しさん** · 2018/10/31(水) 00:30:08.49

東京ミュウミュウ舐めんなよ

**デフォルトの名無しさん** · 2018/10/31(水) 00:34:00.99

サンプルコードにキモさを織り込める偉人だぞ

**デフォルトの名無しさん** · 2018/10/31(水) 01:20:17.24

>>713
1冊じゃないのが許せないよな

赤坂玲音って会社員経験がないんだっけ
確かにそんな感じはする

**651,661** · 2018/11/04(日) 09:16:05.57

SendInput() にINPUT配列を渡してドラッグ＆ドロップをエミュレートすることで対応できました。配列の要素は以下2つ。
ドラッグ開始位置で MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE | MOUSEEVENTF_LEFTDOWN
ドロップ位置で MOUSEEVENTF_ABSOLUTE | MOUSEEVENTF_MOVE | MOUSEEVENTF_LEFTUP

mouse_event()と違ってSendInput()はユーザーのマウス操作の影響を受けづらいはずですが、
マウス移動とマウスボタン操作を別のINPUT要素に入れるとユーザーのマウス操作が入り込んでしまうので、要注意でした。

◆QZaw55cn4c · 2018/11/04(日) 10:52:13.06

>>716
＞赤坂玲音って会社員経験がないんだっけ
書籍を執筆するのに会社員経験は必要ですか？

**デフォルトの名無しさん** · 2018/11/04(日) 11:18:54.43

いるわけねーだろ。バカかよｗ
って馬鹿だからいつまでもくだらない話題ひっぱってんだろうな

**デフォルトの名無しさん** · 2018/11/04(日) 13:01:34.19

GetMessageの戻り値をちゃんと調べる良識人やぞ

**デフォルトの名無しさん** · 2018/11/04(日) 13:46:25.24

GetMessage…
懐かしの踏み絵ですね

**デフォルトの名無しさん** · 2018/11/04(日) 14:04:57.01

エラーを調べるには関数を呼びます

**デフォルトの名無しさん** · 2018/11/04(日) 15:45:01.93

せめてヒントを書いとけよ

ヒント：最後のエラーを取得する関数です
とか

**デフォルトの名無しさん** · 2018/11/04(日) 16:16:20.98

>>722で通じるからｗ

**デフォルトの名無しさん** · 2018/11/04(日) 18:11:10.68

MSが保守投げだしたくなる気持ちは判る

**デフォルトの名無しさん** · 2018/11/04(日) 18:32:10.13

>>724
w

**デフォルトの名無しさん** · 2018/11/04(日) 19:09:01.33

>>724
ｗｗｗ

まいりました

◆QZaw55cn4c · 2018/11/04(日) 19:41:55.05

>>720
＞GetMessageの戻り値をちゃんと調べる

当然なのでは？

while(GetMessage(&msg , NULL , 0 , 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}

メッセージループを抜けるかどうかは、GetMessage() を調べでもしないかぎり分かりようがないのでは？

**デフォルトの名無しさん** · 2018/11/04(日) 19:56:38.13

それバグコードだからｗ

**デフォルトの名無しさん** · 2018/11/04(日) 20:20:15.94

踏み絵がまだ機能しててﾜﾛﾀ

**デフォルトの名無しさん** · 2018/11/04(日) 20:46:13.51

>>728
ちゃんと調べてないぞ

**デフォルトの名無しさん** · 2018/11/04(日) 20:50:35.10

>>729
釣られんなよ…

**デフォルトの名無しさん** · 2018/11/04(日) 22:51:52.16

-1・・・

**デフォルトの名無しさん** · 2018/11/05(月) 13:33:52.85

while(GetMessage(&msg , NULL , 0 , 0) < 0) {

boolじゃないからな

**デフォルトの名無しさん** · 2018/11/05(月) 14:30:24.29

そんなコードばっか書いてるからいつまでも使えないんだよｗ

**デフォルトの名無しさん** · 2018/11/05(月) 17:36:34.14

>>734
エラーの時だけループするのが正しいんですね
勉強になります

**デフォルトの名無しさん** · 2018/11/05(月) 19:35:45.35

>>734
ネタなのかマジなのか判断できねー w

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/11/05(月) 19:41:49.06

while(BOOL bRet = GetMessage(&msg , NULL , 0 , 0)) {
if (bRet < 0) {
MessageBox(NULL, TEXT("異常終了してやんのw ぷぷぷ"), NULL, 0);
break;
}
TranslateMessage(&msg);
DispatchMessage(&msg);
}

**デフォルトの名無しさん** · 2018/11/05(月) 20:01:12.60

無効ポインタを渡してしまった以外にエラーを起こす事あるか？

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/11/05(月) 20:02:50.18

Windows互換を目指すReactOS、
いよいよ明日の夜、リリースです。よろしくね。

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/11/05(月) 20:09:34.41

C/C++では、メッセージループの異常終了に加えてC++の例外と、構造化例外による異常終了があるよ。

◆QZaw55cn4c · 2018/11/05(月) 21:19:04.73

>>740
期待しています！

**デフォルトの名無しさん** · 2018/11/06(火) 05:22:40.71

>>739
そんなもんMSの中の人にしかわからんだろ

**デフォルトの名無しさん** · 2018/11/06(火) 05:47:46.71

ざっと見て2つ目の引数で-返るな

**デフォルトの名無しさん** · 2018/11/06(火) 12:09:16.46

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);
}
}

**デフォルトの名無しさん** · 2018/11/06(火) 12:43:49.56

また頭悪いコードｗ

**デフォルトの名無しさん** · 2018/11/06(火) 12:56:40.18

メッセージループを終了しても永久ループから脱出できない罠

**デフォルトの名無しさん** · 2018/11/06(火) 13:14:59.49

goto最強

**デフォルトの名無しさん** · 2018/11/06(火) 15:07:52.54

std::exception はスレチだし、WndProcから送出してよい例外はWindowsの構造化例外のみだし、送出された構造化例外をWinMainで処理してはいけない

**デフォルトの名無しさん** · 2018/11/06(火) 17:40:05.44

ボケなのマジなのかわからんコードを貼ってるやつはなんなの

**デフォルトの名無しさん** · 2018/11/06(火) 17:48:14.42

真面目に書いてるつもりなんだよ

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/11/06(火) 17:54:13.46

異常終了の際にバックアップを作ってくれるのは、親切なんだろうか。

**デフォルトの名無しさん** · 2018/11/06(火) 19:49:18.62

半分中の人
The Old New Thing
When will GetMessage return -1?
https://blogs.msdn.microsoft.com/oldnewthing/20130322-00/?p=4873/

**デフォルトの名無しさん** · 2018/11/18(日) 16:47:49.39

リストボックスのリストアイテムに、游ゴシックの文字列をイタリック(斜体)で右詰めでDrawText()描画すると見切れてしまうのはどうしたらいいですか？

**デフォルトの名無しさん** · 2018/11/18(日) 17:05:18.33

owner draw

**デフォルトの名無しさん** · 2018/11/18(日) 17:16:58.01

>>755
CDDS_SUBITEM | CDDS_ITEMPREPAINTで owner drawした結果としてのDrawText()なのですが…

**754** · 2018/11/18(日) 17:24:06.74

描画直前に文字列末尾に半角スペースを追加して見切れないようにする対症療法がまず思いつきます。
DrawText()で斜体フォントを右詰め表示するときに最右文字(日本語や欧州語だと末尾文字)が切れてしまうことがあるのは、既知の現象でしょうか？

**デフォルトの名無しさん** · 2018/11/18(日) 17:43:56.83

斜体は必要サイズうまく取得できないからな。別口で取得してそれ使うか、取得値より多少大きくすればいいでしょ

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/11/18(日) 17:47:51.97

斜体のずれの寸法は、tmOverhangだったかな。

**デフォルトの名無しさん** · 2018/11/18(日) 18:13:41.25

>>759
悲報。GetTextMetrics() で得られたtmOverhangはzeroでした。tmItalicはnonzeroが戻ってきているのに。
そんなわけで模範的な解決方法が特にないようなので、文字列末尾に半角スペース追加で対応しようと思います。

**デフォルトの名無しさん** · 2018/11/18(日) 20:31:51.66

原因が斜体の必要サイズ取得なんだから、模範的な方がよければそれぐぐれば一発で出るよｗ

**デフォルトの名無しさん** · 2018/11/18(日) 23:09:34.60

取れないって回答になると思うけどね
新APIとか隠し情報がないと無理かと

**デフォルトの名無しさん** · 2018/11/19(月) 05:02:23.92

リストボックスに限らず、スタティックコントロールも右詰め・游ゴシック・斜体で末尾文字が見切れてしまう。
他のフォントだと見切れが発生しないフォントも多い。描画APIじゃなくてフォント固有の問題に思える。
あと、「見切れる」という北斗の拳っぽい表現、あまり好きじゃないが適切な表現って他にある？

見切れる(ミキレル)とは - コトバンク
https://kotobank.jp/word/%E8%A6%8B%E5%88%87%E3%82%8C%E3%82%8B-673764
　１テレビ放送や演劇で、本来見えてはいけないものが見えてしまう。「裏方スタッフが―・れる」
　２写真や映像で、フレームに人物などの全体が収まらず、一部が切れている。「集合写真で端の人が―・れる」

**デフォルトの名無しさん** · 2018/11/19(月) 05:48:21.80

https://www.google.co.jp/search?q=斜体+サイズ+取得+windows+api&oq=斜体%E3%80%80サイズ%E3%80%80取得+windows+api