Win32API質問箱 Build126

**デフォルトの名無しさん** · 2020/05/01(金) 22:16:51.96

Win32APIについての質問はこちらへどうぞ。

■注意
・質問する前にMSDNライブラリやPlatformSDK、Google等で検索しましょう。
・日本語版MSDN Online Libraryは不完全です。
　英語版( http://msdn.microsoft.com/en-us/library/ )の利用推奨。
・APIフックなど高度な事をしたい場合はできるだけAdvenced Windowsを読みましょう。
・言語特有の問題やIDE、MFCやVCLなどの質問はそれぞれの言語や開発環境スレで

■過去スレ
Win32API質問箱 Build125
https://mevius.5ch.net/test/read.cgi/tech/1551247748/
Win32API質問箱 Build124
https://mevius.5ch.net/test/read.cgi/tech/1510395780/

■関連スレ
Visual Studio 2019 Part4 https://mevius.5ch.net/test/read.cgi/tech/1585715794/
Visual Studio 2017 Part7 https://mevius.5ch.net/test/read.cgi/tech/1558179898/
【C++】 DirectX初心者質問ｽﾚ Part41 【C】 https://mevius.5ch.net/test/read.cgi/tech/1521786252/

**デフォルトの名無しさん** · 2021/06/01(火) 03:20:20.18

詳しく

**デフォルトの名無しさん** · 2021/06/01(火) 16:25:48.20

思わせぶりなんやな

**デフォルトの名無しさん** · 2021/06/01(火) 16:31:57.56

>>580
完璧に監視したいならカーネルドライバ仕込むしかなさそうか

**デフォルトの名無しさん** · 2021/06/02(水) 04:00:06.74

完璧かどうか忘れたが、登録し直しなんてやった記憶ないな

**デフォルトの名無しさん** · 2021/06/02(水) 11:14:04.96

登録し直しなんてやった記憶無いし
しなくても通知は来ることは来るけど
ちゃんとしてても普通に取りこぼすことはあった気がする

**デフォルトの名無しさん** · 2021/06/03(木) 00:06:10.42

>>585>>586
それはSHChangeNotifyRegisterの話？
もしくはReadDirectoryChangesExWでもIO完了ポートで受け取る方式なら継続的になるとか？
完了ポートでの非同期IQはややこしそうだからとスルーしていたが

**デフォルトの名無しさん** · 2021/06/03(木) 19:50:54.55

>>587
585だけど昔のソース見たら専用スレッドで下みたいなことしてた。登録し直してるわ
OVERLAPPED ol;
ol.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);

for (;;) {
bRet = ReadDirectoryChangesW( hDir, buffer, buffer_size, TRUE,
FILE_NOTIFY_CHANGE_FILE_NAME |FILE_NOTIFY_CHANGE_LAST_WRITE|FILE_NOTIFY_CHANGE_SIZE |FILE_NOTIFY_CHANGE_CREATION|FILE_NOTIFY_CHANGE_SECURITY
, &dwByte, &ol, NULL);

ol.hEvent を WaitForMultipleObjects で待つ

bRet = GetOverlappedResult(hDir, &ol, &dwByte, TRUE );

for (;;) {
pInfo = (FILE_NOTIFY_INFORMATION *)&buffer[i];

別スレッドの待ち行列に追加

if (pInfo->NextEntryOffset == 0)
break;
i += pInfo->NextEntryOffset;
}
}

**デフォルトの名無しさん** · 2021/06/07(月) 03:29:32.93

タッチスクリーンとして扱われる入力デバイスがあるのですが、これをマウスのように扱いたいです。
具体的に言うと、ブラウザ等のアプリ上でWM_POINTERDOWNが発生した時点でマウスの左クリックと同等の動きをさせ、POINTERDOWN以外のWM_POINTER系メッセージを握り潰したいです。

SetWindowsHookEx()で、起動中の各アプリケーションに対して自作dll内のフックプロシージャをインストールしたのですが、下記StackOverflowの投稿と同じ状態になって詰まっています。
https://stackoverflow.com/questions/21069643/is-it-possible-to-remove-touch-messages-wm-pointerdown-etc-that-an-applicatio

フックタイプにWH_CALLWNDPROCを指定すればメッセージの握り潰しや書き換えができるようなのですが、その場合どのようなウィンドウメッセージをフックすれば良いのでしょうか？

**デフォルトの名無しさん** · 2021/06/12(土) 10:06:00.61

このスレでいいのか判りませんが質問です。
WindowsのタブレットはUSBマウス等のポインティングデバイスを差さないとマウスカーソルが表示されないのですが、
APIか何かでマウスカーソルを表示させる方法ってありませんか？
タブレットでSendInputで自動操作させる時にマウスカーソルが表示されず、何が起こっているのか判らないので何とかしたいです。
kokomiteみたいなソフトも試しましたが、ログイン前とかでは使えないので他の方法がないか探しています。

**デフォルトの名無しさん** · 2021/06/12(土) 14:25:29.90

マウスジグラーを繋ぐとかは抜きなら
DDKじゃね

**デフォルトの名無しさん** · 2021/06/12(土) 14:30:19.46

SetProp(), GetProp() っていつごろからあるんだろう？
これらの関数の存在を最近まで知らなかった

**デフォルトの名無しさん** · 2021/06/12(土) 14:35:57.37

>>592
Windows 2000

**デフォルトの名無しさん** · 2021/06/12(土) 15:21:40.84

>>593
回答ありがとう

HWNDにユーザ定義構造体を紐づけて管理できるのはかなりありがたい。
今まで20年以上知らなかったのは、我ながら恥ずかしい。

**蟻人間** ◆T6xkBnTXz7B0 · 2021/06/12(土) 18:39:01.20

SetProp/GetPropはstd::mapみたいに使えて便利だが、システムやアプリが無断で勝手に使う関係ないデータが交じる恐れがあるから注意。

◆QZaw55cn4c · 2021/06/12(土) 19:56:59.39

>>594
WindowClass.cbClsExtra や WindowClass.cbWndExtra にポインタのサイズを登録しておいて、
::CreateWindow(..., this)
::SetWindowLong()/::SetWindowLongPtr()
::GetWindowLong()/::GetWindowLongPtr()
とかをやる手法は win3.1 からあったと記憶しています

>>593,592
https://docs.microsoft.com/en-us/windows/win32/winmsg/using-window-properties
を初めてみていますが、Window Properties とはどういう概念でしょうか？みたところ上記の api 群が扱うオブジェクトとは違うようですが

**デフォルトの名無しさん** · 2021/06/12(土) 20:53:52.52

>>596
はい。ご紹介いただいた関数は知ってましたが、
ユーザー定義データをひとつしか登録できないので、使うのを避けてました

**590** · 2021/06/13(日) 08:15:12.76

>>591
>マウスジグラー
こういう製品があるんですね。ご紹介ありがとうございます。
ただ、機能の割にお値段が結構するみたいなので、無線マウスのドングルでも繋いどけばよさそうですね。
仮想マウスドライバの作成も検討してみます。
ありがとうございました。

**デフォルトの名無しさん** · 2021/06/13(日) 14:01:31.30

SetCursorでダメなん

**デフォルトの名無しさん** · 2021/06/14(月) 01:35:24.65

>>599
SetCursor、ShowCursorを試してみましたがだめなようです。
マウスカーソルがが表示されない状態の簡単な再現方法ですが、
Windows10が入った適当なデスクトップPCにマウス等を繋がずに起動するとこの状態になるようです。

**デフォルトの名無しさん** · 2021/06/14(月) 10:46:03.90

GetTickCount()

東京五輪期間中の49日間、在宅勤務を求めた政府に「不吉」の声 - ライブドアニュース
https://news.livedoor.com/article/detail/20359990/

**デフォルトの名無しさん** · 2021/06/14(月) 14:11:06.25

もともとテレワークだから関係ないけど
夏期休暇中にバリバリ旅行する予定は入れてるな
ハハハ

**デフォルトの名無しさん** · 2021/06/14(月) 20:25:26.99

49.7日間で終わるのが嫌ならGetTickCount64()を使えばいい

**デフォルトの名無しさん** · 2021/06/14(月) 21:41:37.22

今さらだがGetTickCountで四十九日という考え方をしたことないけど、覚え方としてはありか

**デフォルトの名無しさん** · 2021/06/14(月) 21:44:55.35

95時代から何度もトラブルを起こしている
49日deathと名前が付くぐらいだし

**590** · 2021/06/14(月) 21:54:18.56

次の設定でマウスカーソルが表示できました。

Windowsの設定 → 簡単操作 → マウス → マウスをキーパッドで操作する：オン

または下のレジストリ設定後、一度ログアウトし再度ログオンする。
rem マウスオン
reg add "HKCU\Control Panel\Accessibility\MouseKeys" /v Flags /t REG_SZ /d "159" /f
rem マウスオフ
reg add "HKCU\Control Panel\Accessibility\MouseKeys" /v Flags /t REG_SZ /d "158" /f
レジストリ設定の場合、一度ログアウトが必要なのが解せませんが、これで一応ソフトウェアでカーソルの表示まではできました。

**590** · 2021/06/14(月) 22:00:24.26

なお、ログオフ前もマウスカーソルを表示させたい場合はHKU\.DEFAULTに設定すれば良いようです。
reg add "HKU\.DEFAULT\Control Panel\Accessibility\MouseKeys" /v Flags /t REG_SZ /d "159" /f
とりあえずこれで大丈夫かな？

**デフォルトの名無しさん** · 2021/06/15(火) 20:39:42.52

>>605
Vistaでいろいろ作り直されたせいで497日になったのが笑えた
当時2008R2動かしてたサーバが引っ掛かりまくったわ

**デフォルトの名無しさん** · 2021/06/18(金) 04:52:47.87

こんにちは。
C++ でSDIウィンドウを管理するためのラッパークラスを作っているのですが、
正直、継承クラスを作成してウィンドウをカスタマイズするたびに新しい
ウィンドウクラス名を指定する作業が面倒くさいです。当初は

　string SDIWindow::get_wndclass_name() const {return typeid(*this).name();}

このような仮想関数を用意していたのですが、std::typeid::name() の返却値は実装依存で、
空文字すら返すことがあると聞き、ボツ案になりました。どうにかウィンドウクラス名を
自動生成したいのですが、妙案はありませんでしょうか。MFCなどのツールではどのように
名前を付けているのでしょう？よろしくお願いいたします。

**デフォルトの名無しさん** · 2021/06/18(金) 11:13:45.48

>>609
自分でMFCヘッダーを探せばいいことを、わざわざ質問すべきではありません
質問を取り下げてください

**蟻人間** ◆T6xkBnTXz7B0 · 2021/06/18(金) 19:51:49.70

>>609
コンストラクタで__func__を使ってみたらどう？

**デフォルトの名無しさん** · 2021/06/18(金) 20:14:25.45

ATLはオブジェクトのアドレスだったような

**609** · 2021/06/19(土) 01:33:45.59

ご回答くださった方々、ありがとうございます。
__func__ これだ、と思ったのですが、いま使用しているコンパイラが相当古く、
この機能をサポートしていないようです。何かうまい方法がないかもう少し考えてみます。

>>612
自分もオブジェクトのアドレスを利用できないかと考えていたのですが、インスタンスごとに
アドレスが異なると困るのではと思い、保留していました。

**デフォルトの名無しさん** · 2021/06/19(土) 05:54:37.84

uid、guid生成すんのがトレンド

**デフォルトの名無しさん** · 2021/06/19(土) 13:13:08.67

コンストラクタの呼び出し位置で __FILE__と__LINE__を使った文字列をセットするとか

**609** · 2021/06/19(土) 15:58:26.49

>>614-615
ありがとうございます。
なるほど！　__FILE__, __LINE__ の組み合わせは盲点でした。
これなら確かに、オブジェクトとウィンドウクラスを1対1で対応させることができますね。
少なくとも当座はこれでしのげます。
uid、guid 案もありがとうございます。
知識不足のため、勉強してから考えてみたいと思います。

**デフォルトの名無しさん** · 2021/06/19(土) 16:18:13.72

ウインドウクラス名は文字列の他にATOMでも指定できる
ATOMはRegisterClass()が返す

**デフォルトの名無しさん** · 2021/07/09(金) 07:17:28.46

dllmainの最初の引数のHMODULEっていうかハンドルと同じ値を取得するwin32apiある？

ライブラリ作ってるけど、dllmain自体をライブラリに含めたくないから困ってる。

dllmainからHMODULEをライブラリに渡せ
みたいな変な規則も出来れば避けたい...

**デフォルトの名無しさん** · 2021/07/09(金) 07:19:48.14

GetModuleHandle(NULL)をキャストしる

**デフォルトの名無しさん** · 2021/07/09(金) 07:50:25.45

GetModuleHandleのNULLは大元の実行ファイルのパス。
そうじゃなくて.dllのパスが欲しい。
その際dllmainの第一引数を使わない形で欲しい。

**デフォルトの名無しさん** · 2021/07/09(金) 08:17:41.20

んでリンカーでエントリーポイントを自前のにしつつ
ｺﾝﾊﾟｲﾗのｽﾀｰﾄｱｯﾌﾟに渡す過程で hInst をくすねるしかないんじゃないの？

**620** · 2021/07/09(金) 08:53:28.23

定義関数自身を渡しつつ、リファレンスカウンタを増やすのを回避する以下の形でいけるっぽい。
HMODULE GetCurrentModule()
{
DWORD flags = GET_MODULE_HANDLE_EX_FLAG_FROM_ADDRESS | GET_MODULE_HANDLE_EX_FLAG_UNCHANGED_REFCOUNT;
HMODULE h = 0;
::GetModuleHandleEx(flags, reinterpret_cast<LPCTSTR>(GetCurrentModule), &h);
return h;
}

**デフォルトの名無しさん** · 2021/07/09(金) 11:00:40.24

そのライブラリを利用して
dll を記述するときは dll 自身を指して
アプリケーションを記述するときは実行ファイル自身を指すと

(GetModuleHandle() は、常に実行ファイルを指す)

**デフォルトの名無しさん** · 2021/07/09(金) 12:53:16.14

Module32First でも使えば～

**デフォルトの名無しさん** · 2021/07/09(金) 16:42:11.88

>>618
DLLは、アプリと同じ仮想アドレス空間を共有しており、HMODULEの値は、
DLLの PE イメージの先頭アドレスだと聞いている。
そして、DLLは単なる関数の集まりに過ぎないので、「現在のDLL」という
概念が存在しない。
dllmain が呼び出されて、OSに戻るまでの間の時間、現在どの dllmain が呼び出されているか、
という情報なら OSはどこかに持っているはずではあるが。
なお、DLLの関数群は、通常、dllmain が呼び出されている間以外に使うことが原則。

**デフォルトの名無しさん** · 2021/07/10(土) 05:25:42.40

dllは現在実行中のdllという概念はあるのでは。
あるからこそ、c++/cliでは簡単かつ確実なものとして提供されてるわけで。

**デフォルトの名無しさん** · 2021/07/10(土) 05:59:03.94

あと、現在実行中のニーモニックのアドレスより若い直近アドレスに位置するモジュールのエントリーアドレスであればそれが求めるものだし。
620は関数定義が属するdllのハンドルを得る関数になってるから、実用上問題なく機能するよね。

**デフォルトの名無しさん** · 2021/07/10(土) 06:50:44.17

そもそもDllMainのHMODULEを使わないって縛りプレイでのお話でおすし

**デフォルトの名無しさん** · 2021/07/10(土) 09:10:30.89

>>626
そういう概念は無い。
dllmain() は、DLL が最初にロードされたとき、スレッドが開始するとき、
及び、それらの終了する時に呼び出されるエントリ関数に過ぎない。

**デフォルトの名無しさん** · 2021/07/10(土) 09:18:08.53

>>618
> ライブラリ作ってるけど、dllmain自体をライブラリに含めたくないから困ってる。

そういのだとリンカーとかの話で、APIでどーとかってのとはまた違うような

**デフォルトの名無しさん** · 2021/07/10(土) 09:39:49.89

>>629
[補足]
「現在ロード中で使用中の DLL」
という概念ならある。

**デフォルトの名無しさん** · 2021/07/10(土) 09:41:14.25

>>621
[補足2]
2つ以上のDLLを使用中の場合は、その内のどのDLLのどの関数が今まさに「実行中」か
どうかは、OSレベルでは管理されてないという意味で言っている。

**デフォルトの名無しさん** · 2021/07/10(土) 09:41:47.91

>>632
>>631 へのアンカーミスだった。スマン。

**デフォルトの名無しさん** · 2021/07/10(土) 09:43:15.11

tool help 32

**デフォルトの名無しさん** · 2021/07/10(土) 11:50:04.86

いや実行中のステップがどのdllかという概念はあるよ。
あるからデバッガでも今の瞬間実行中のステップがどの.dllのどのアドレスかまでわかってるわけで。

**デフォルトの名無しさん** · 2021/07/10(土) 11:56:56.14

>>635
それをOSが管理してるか？って話だろ

**デフォルトの名無しさん** · 2021/07/10(土) 12:01:47.23

各々dllのベースアドレスは管理してるんだから、管理してるだろ。
管理してるかはdllは解放されるんだろ？
ベースアドレスからファイル名が辿れるから何のファイルか解るようになってるんやないか。
だからぶっ飛ぶとシステムログに飛んだdll名が明記されるやないか。

**デフォルトの名無しさん** · 2021/07/10(土) 13:28:51.32

本当に飛躍した話が好きだよなおまえ達は

**デフォルトの名無しさん** · 2021/07/10(土) 13:41:35.94

GetModuleHandleExの仕様をみればOSの管理下にあるのわかるじゃん。

2番目の引数には。モジュールのパスでもよいが、
「モジュール内の任意のアドレス」でもいいわけ。
即ち今プログラムでましに実行中位置であるEIPレジスタやRIPレジスタの値から
dllなりexeなりのハンドルがとれると書いてあるわけで。
もちろんハンドルがとれるからファイルのパスもわかる。

管理下になかったらどうやって取れるんだってのw

**蟻人間** ◆T6xkBnTXz7B0 · 2021/07/10(土) 14:24:30.76

ReactOSでGetModuleHandleExWをたどってみると次のようになる：

https://github.com/reactos/reactos/blob/master/dll/win32/kernel32/client/loader.c#L866
https://github.com/reactos/reactos/blob/master/dll/win32/kernel32/client/loader.c#L716
https://github.com/reactos/reactos/blob/master/dll/win32/kernel32/client/loader.c#L767
https://github.com/reactos/reactos/blob/20c1da7963debb69a46cf9f19f3e4c5e504c7fc9/ntoskrnl/rtl/libsupp.c#L34
https://github.com/reactos/reactos/blob/3fa57b8ff7fcee47b8e2ed869aecaf4515603f3f/ntoskrnl/ke/bug.c#L41

PLDR_DATA_TABLE_ENTRY構造体でプロセスの空間を保持しているようだ。

**デフォルトの名無しさん** · 2021/07/10(土) 15:12:39.28

>>637
> 各々dllのベースアドレスは管理してるんだから、管理してるだろ。
それは
>> 「現在ロード中で使用中の DLL」
な

**デフォルトの名無しさん** · 2021/07/10(土) 15:26:13.52

でも結局CPUの命令アドレスからdll名を求められるから、
今CPUが実行中のdllやexeはOSが管理してるし、それ用のwin32apiも提供されている、であってるやん。

**デフォルトの名無しさん** · 2021/07/10(土) 15:45:03.11

どこを実行中かをOSが管理してるなら、暴走なんてせんわな
デバッガはbreakしたらやってるだけ

**デフォルトの名無しさん** · 2021/07/10(土) 16:12:20.61

>>642
dllを実行中かなんて管理してないぞ
単にスタックの戻りアドレスから.dll検索してログに書き込んでるだけ

**デフォルトの名無しさん** · 2021/07/10(土) 16:44:08.48

プロセス単位でexeやdllのアドレスを簡易的に言えば配列のように保持してて
あとはEIPが配列のインデックスであるかのように実行時に動くだけだから管理できてるじゃん。

indexに幅があるってだけでしょ。

**デフォルトの名無しさん** · 2021/07/10(土) 17:41:11.37

>>645
OSはEIPを管理なんてしてないぞ
そもそもぶっ飛んだ時に関数レベルのスタックトレースができるからと言ってOSがどの関数を実行してるかを管理してるとでも言うのか？

**デフォルトの名無しさん** · 2021/07/10(土) 17:43:28.93

激重OSになりそう

**デフォルトの名無しさん** · 2021/07/10(土) 18:58:44.17

いったいいつ関数の話になったんだ。
EIPからいつでもモジュールを辿れる形でプロセス情報を保持してるから管理されてると言ってるんだが。

プロセス情報を保持してないなら管理してないと言えるが。

**デフォルトの名無しさん** · 2021/07/10(土) 19:18:42.88

管理されてるを監視してるに勝手に脳内で置き換えてないやろな？

**デフォルトの名無しさん** · 2021/07/11(日) 00:19:00.34

でそれを取得するAPIは？

**デフォルトの名無しさん** · 2021/07/11(日) 03:01:15.31

管理されているというより、EIPアドレスから逆算しているという感じだね。
実行中のマシン語の命令のアドレスが分かれば、リンク時のマップファイルのような
情報があれば、どの関数の中のマシン語かまで分かるから。

**デフォルトの名無しさん** · 2021/07/11(日) 03:07:37.40

どの人がどこにいるかを国は普段は追跡してないけど、科学捜査すればどこにいるか
分かることが多いと言う意味で、「管理はしてなくても見抜くことは出来る」
のと同様の事。

**デフォルトの名無しさん** · 2021/07/11(日) 03:11:46.75

>>649
各DLLがロードされている場所のアドレス範囲とEIPさえあれば、そりゃ、どのDLL
にいるかは分かるけれど、それは管理とは言わないと思うな。
マシン語で、jmp アドレス、call アドレスで、1クロックですぐに EIP = アドレス
になるが、それをOSはいちいち追跡も管理も全くしていない。だから、
現在どのDLLの関数を実行中かをOSは情報としては持ってない。
ところが、EIPの値からどのDLLの中を実行中かを「逆算」することが可能と言うだけ。

**デフォルトの名無しさん** · 2021/07/11(日) 03:17:09.08

プログラミングの世界で「管理」というのは、
struct SomeInfo {
　int curDllIndex;　// 現在実行中のDLLのインデックス番号(0-)
};
のようなデータ構造があり、idx1 という番号の DLL の中の関数を呼び出すときに、
プログラムで curDllIndex = idx1 にちゃんと書き込む、ということをイメージする。
このような意味での書き込みは行われてない。

**デフォルトの名無しさん** · 2021/07/11(日) 03:24:26.40

OSに管理されているのであれば、idx1 番の DLLから、main モジュールの関数 f()が
コールバックされたような場合でも、どのDLLから呼び出されたかまで分かるはずだが、
現実にはEIPは、f()の中をポイントしているから EIP だけからは、idx1 を逆算する
ことは不可能。
デバッガが出来てしまうのは、デバッグしやすい様にコンパイラが
「スタックフレーム」という構造が出来るようなコードをわざと作っているから。
その構造によれば、スタックとEBPの値で呼び出しもとの関数の履歴を全て辿って
いける。
しかしこれは、OSが管理しているのではなく、デバッグ版ではそのようなコードを
コンパイラが生成しているからに過ぎない。
リリース版では効率向上のためスタックフレームが省略されることもあり、その
場合は呼び出しもとの関数が辿れなくなるので idx1 という番号を算出することは
原則的には出来なくなる。

**デフォルトの名無しさん** · 2021/07/11(日) 03:33:02.64

>>655
[補足]
スタックフレームは、「ユーザーランド」のアドレス空間に構成された構造で、
OSが「管理」する「システムランド」のアドレス空間にはない。
前者はプログラムに誤りが有ると壊れることがあるし、コンパイラのオプション次第
で省略されることもあるから、いつでも存在するわけでも無いし、いつでも正しい
訳でもない。
その意味で、OSの管理する構造ではない。

**デフォルトの名無しさん** · 2021/07/11(日) 03:48:47.46

Tool Help Library ぐらいは調べて
から書きたまえ。

**デフォルトの名無しさん** · 2021/07/11(日) 07:22:23.17

>>657
オタクが調べて書けばいいんじゃね？
何を書きたいのか知らんけどw

**デフォルトの名無しさん** · 2021/07/11(日) 09:13:47.20

とっくに書いてるよばーか

**デフォルトの名無しさん** · 2021/07/11(日) 09:20:59.49

「管理」の定義が独り歩きしているがもともとは>>629-632だろ？
その意味では「管理」されているでいいんじゃね？

**デフォルトの名無しさん** · 2021/07/11(日) 10:40:25.91

>>659
どこに書いてあるのかレス番示して引用してみ
どうせ逃げるなら速い目に頼むw

**デフォルトの名無しさん** · 2021/07/11(日) 10:42:50.54

>>660
それに対する>>635がおかしいって言われてるんだろ

**デフォルトの名無しさん** · 2021/07/11(日) 10:50:14.49

これは話をループさせる手段なのか？ｗ

**デフォルトの名無しさん** · 2021/07/11(日) 11:20:11.96

「Hacking: 美しき策謀」ぐらいは読んでこいよ

**デフォルトの名無しさん** · 2021/07/11(日) 11:49:37.25

本当に管理されていると言うのなら、別のlibで定義されている
HMODULE get_this_dll_module();
という関数によって、あらゆるDLLのHMODULEを取得できるようになるはずで
あるが、この関数は、スタックフレームを前提にしない限りは基本的に
作ることが出来ない。なぜなら
void get_this_dll_module() {
　// ここの EIP の値は、呼び出しもとの DLL のものとは違っている。
}
からである。

**デフォルトの名無しさん** · 2021/07/11(日) 11:51:10.61

>>665
誤: void get_this_dll_module()
正: HMODULE get_this_dll_module()

EIPのアドレスは、簡単に変わりうるものなのだ。

**デフォルトの名無しさん** · 2021/07/13(火) 12:38:32.06

だらだらしてるので
3行でまとめてくれ

**デフォルトの名無しさん** · 2021/07/13(火) 12:47:15.46

>>667
現在の関数からその関数が格納されているDLLのパスまで取得できる情報があることを
OSが管理していると呼ぶかどうかで
外野がうんこの投げ合いをしている

**デフォルトの名無しさん** · 2021/07/13(火) 13:19:09.51

そういうのは動物園でやれよ

**デフォルトの名無しさん** · 2021/07/13(火) 13:50:43.04

無駄な議論ではなく、質問者が、現在実行中の関数の所属する
DLLを正確に取得する方法があると思い込んでいた可能性があるので
大事な指摘だった可能性がある。
結論から言えば、安定してそれを取得する方法は無い。

**デフォルトの名無しさん** · 2021/07/13(火) 14:46:12.78

質問者は普通に安定した方法で自己解決していったな

**デフォルトの名無しさん** · 2021/07/13(火) 16:28:34.84

get_this_dll_moduleてなんなんってぐぐったら
このスレが引っかかってわろた
脳内の関数だったか

**デフォルトの名無しさん** · 2021/07/13(火) 17:47:39.31

未解決のせいで盛り上がってたのかと思ったら>>622で解決してたのか

**デフォルトの名無しさん** · 2021/07/14(水) 20:59:18.35

>>620
他のこと調べてたら見つけたけど__ImageBaseって変数のアドレスがまさに目的そのものっぽいわね

https://devblogs.microsoft.com/oldnewthing/20041025-00/?p=37483

**デフォルトの名無しさん** · 2021/07/14(水) 21:06:59.94

「D:\aaaa\bbbb」などの、ファイルやフォルダのパス名から、
そこがCDやDVDなどの光学ドライブかを判定する仕組みはありますか？

**デフォルトの名無しさん** · 2021/07/14(水) 21:11:04.17

GetLogicalDriveStringsかな

**デフォルトの名無しさん** · 2021/07/14(水) 21:13:56.34

途中送信ごめん

全ドライブ文字と種類がわかるから
後は比較するオレオレ関数作る感じ

**デフォルトの名無しさん** · 2021/07/14(水) 21:15:40.83

何度もごめん

種類はGetDriveTypeね

**デフォルトの名無しさん** · 2021/07/14(水) 21:36:03.70

>>678
ありがとうございます。
GetDriveTypeは、"D:\"の3文字の部分しか渡せないようですが、
PathGetDriveNumberでも使えば、"D:\"の部分だけを作れそうですね。

**デフォルトの名無しさん** · 2021/07/15(木) 01:52:58.00

リッチエディットに複数行の文字列をプログラムから定期的に送って全内容を更新するプログラムを作成しています。
更新中は垂直スクロールバーで任意の行に移動できるようにしています。
コードは下記です。

LRESULT Line = SendMessage( hEdit, EM_GETFIRSTVISIBLELINE, 0, 0 ); // 現在の表示行を控えておく

SendMessage( hEdit, WM_SETREDRAW, FALSE, 0 ); // 文字列更新中の状態が露呈しないよう再描画を抑制する

SetWindowText( hEdit, str ); // 全文字列更新

SendMessage( hEdit, EM_LINESCROLL, 0, -INT_MAX ); // 表示行を一番上に移動する
SendMessage( hEdit, EM_LINESCROLL, 0, Line ); // 表示行を、控えておいた位置に移動する

SendMessage( hEdit, WM_SETREDRAW, TRUE, 0 ); // 再描画再開

InvalidateRect( hEdit, NULL, FALSE ); // 表示を促す

これで、ある程度までの行数の文字列であれば、意図通りの挙動となるのですが、
行数が多くなってくると、動かしていたスクロールバーが一瞬一番下まで下がってから
元の位置に戻るという現象が文字列更新の度に起こります。
ただ、リッチエディット内の表示位置は、動かしていたスクロールバー位置に対応する位置のままで、
スクロールバーが一瞬一番下がる動きとは連動しません。

一体何が起こっており、どのようにすれば回避できそうでしょうか？

**デフォルトの名無しさん** · 2021/07/15(木) 09:58:52.50

もしかしてそれって32767行くらい超えてから？

**680** · 2021/07/15(木) 12:02:49.75

>>681
改行文字(\n)だけの80行くらいでも発生しました。
そして>>680の内容に訂正があります。
>動かしていたスクロールバーが一瞬一番下まで下がってから
は、一番下までは下がっていませんでした。
また、下がったときはバーが長くなっており、
あたかも行数が少なくなったかのよう(エディット内の表示は意図通り)な挙動です。
さらに、以下のような性質も分かりました。

・スクロールバー位置が一番上のときは一瞬下がる症状が発生しない
・スクロールバー位置が一定より下になると一瞬下がる症状が発生しない
　・この位置は全体行数とリッチエディットの縦幅との関係によって変わり、
　　スクロールバーの長さが全体の大半を占める場合はどの位置でも発症しなくなる