Win32API質問箱 Build127

**デフォルトの名無しさん** · 2021/12/09(木) 21:32:56.60

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

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

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

■関連スレ
Visual Studio 2020 Part1 https://mevius.5ch.net/test/read.cgi/tech/1634166667/
Visual Studio 2019 Part7 https://mevius.5ch.net/test/read.cgi/tech/1634178709/
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/

**デフォルトの名無しさん** · 2025/01/30(木) 09:05:49.08

毎回読んでるに決まってるだろ

**デフォルトの名無しさん** · 2025/01/30(木) 17:56:26.05

win16時代からなんかモヤモヤする気持ち悪い部分だねｗ

**デフォルトの名無しさん** · 2025/01/30(木) 19:54:33.33

メモリなんてほとんど無かった時代からあるものだから、キャッシュなんてしてるわけないしな

**デフォルトの名無しさん** · 2025/01/30(木) 20:05:36.27

VistaくらいからならOSのファイルキャッシュが勝手に働いてそう。

**デフォルトの名無しさん** · 2025/01/31(金) 01:11:17.59

キャッシュなんかMS-DOSのsmartdriveあたりからあるだろ
無効にするとWindows3.1は遅かった記憶がある

**デフォルトの名無しさん** · 2025/01/31(金) 10:55:21.33

>>935
構文解析なんて一瞬で終わる
キャッシュはOSがリファレンスカウントで管理してるでしょ
ただしゼロになったからといって直ぐに解放する訳じゃないし、ゼロになる前に解放される場合もある
そこは空きメモリとの兼ね合いでOSが上手くやる

**デフォルトの名無しさん** · 2025/01/31(金) 12:27:33.25

補足すると再起動後やスリープ復帰後に$MFTを舐める様なアプリを動かしておくとシステムキャッシュに載って
その後はHDDでもSSDと同様にディレクトリトラバーサルがマルチスレッドで高速化する(find/fd等)
(よくある専用ソフトを常駐させなくてよい)

**デフォルトの名無しさん** · 2025/02/13(木) 21:31:19.77

メインウィンドウのウィンドウプロシージャをグローバルからクラスメンバに移したくて
一応表面的なエラーなどは出ずに起動したのですが問題ないのか不安です
断片的で分かりにくいかもですが以下で問題ないか教えていただけないでしょうか

wc.lpfnWndProc = DefWindowProc;

SetWindowSubclass( hwnd, SubProc, 1, reinterpret_cast< DWORD_PTR >( this ) );

static LRESULT CALLBACK SubProc( HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam, UINT_PTR uIdSubclass, DWORD_PTR dwRefData );

LRESULT CALLBACK MyWindow::SubProc( HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam, UINT_PTR uIdSubclass, DWORD_PTR dwRefData )
{
MyWindow *pThis = reinterpret_cast< MyWindow * >( dwRefData );
switch( uMsg )
{
　　　...
}
return DefSubclassProc( hwnd, uMsg, wParam, lParam );
}

**デフォルトの名無しさん** · 2025/02/14(金) 05:52:04.48

あかんやろな

**デフォルトの名無しさん** · 2025/02/14(金) 08:53:53.37

20年以上前にMFCみたいなラッピングクラス群を自前で作ってみたことあったけど
ウィンドウプロシージャのとこをどうやったかもう忘れてしまったな……

**デフォルトの名無しさん** · 2025/02/14(金) 13:37:08.02

メソッドという事は、第一引数にthisが渡る必要がある。
コールバックプロシジャーの呼び出し側にその機能(thisを積む)は無い。

MFCはその部分マクロで展開していたね

**デフォルトの名無しさん** · 2025/02/14(金) 14:04:52.13

Best method for storing this pointer for use in WndProcにMethod 1~6まで解説されてるわ

>>946
ATLだとMethod 5: Thunkだね

**デフォルトの名無しさん** · 2025/02/14(金) 19:58:04.34

俺がやったやり方書いてやろうとしたらNGワード言われてBBxまでされたわｗ
クソじゃんｗ

**デフォルトの名無しさん** · 2025/02/14(金) 21:57:56.25

method 4のやり方だし行けるんじゃない？
自分はmethod 6のイマイチ泥臭い方法でやったよ

**デフォルトの名無しさん** · 2025/02/14(金) 22:08:59.93

一次受け用のstaticなプロシージャとクラスのメソッド
あとSetPropとSetWindowLong使ってやったな確か

**デフォルトの名無しさん** · 2025/02/27(木) 22:08:23.91

SetWindowSubclass

**デフォルトの名無しさん** · 2025/02/28(金) 06:34:40.22

今更ｗ

**デフォルトの名無しさん** · 2025/02/28(金) 08:53:25.56

俺がその手のことやった時はSetWindowSubclass無かったな

**デフォルトの名無しさん** · 2025/02/28(金) 17:04:57.17

次スレよろ

**デフォルトの名無しさん** · 2025/03/04(火) 10:30:55.31

Win32はいつ廃止されるの？

**デフォルトの名無しさん** · 2025/03/04(火) 15:36:03.05

.netベースのWinFXが完成したら順次廃止していくらしい

**デフォルトの名無しさん** · 2025/03/04(火) 15:50:19.15

.NETベースだと2年で切り捨てられていくのか……
大変だなぁ

**デフォルトの名無しさん** · 2025/03/04(火) 17:51:40.09

Windows上の.NETがそもそもAPI呼んでるのにどうやって廃止するのｗ

**デフォルトの名無しさん** · 2025/03/04(火) 18:04:09.20

Win32APIを呼ばない.netになるんじゃね？
android版とかそうなってないの？

**デフォルトの名無しさん** · 2025/03/05(水) 06:08:30.10

WinFXて、.NET Framework 3.0の開発コードだが……

**デフォルトの名無しさん** · 2025/03/05(水) 08:44:01.42

そもそもWin32APIを捨てるとか、Windowsをイチから作り直さないと不可能だろ

**デフォルトの名無しさん** · 2025/03/05(水) 12:33:13.43

着々と64bit化は進められてるぞ
今やレガシーアプリの為だけに32bit対応があるだけだからなぁ

**デフォルトの名無しさん** · 2025/03/05(水) 12:35:52.90

昔あったPowerPC、ItaniumのWindowsにもWin32apiあるの？

**デフォルトの名無しさん** · 2025/03/05(水) 15:45:08.28

>>962
>>963
内部的なbitサイズの違いや呼称の差であって、Windows APIのインターフェースが変わってるわけじゃないぞ

**デフォルトの名無しさん** · 2025/03/05(水) 23:09:43.33

>>963
なくてどうする

**デフォルトの名無しさん** · 2025/03/05(水) 23:21:28.24

https://github.com/microsoft/win32metadata
このwin32metadataプロジェクトでモダンな言語からも簡単に使えるようになった
あらゆる機能をWin32で公開してwin32metadataも更新すれば、色んな言語から直ぐ使えるようになる
なのでWin32を廃止する意味が無くなった

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

64bitのCのintとかlongって32bitなん？
64bitあるのはlonglongとsize_tだけ？

**デフォルトの名無しさん** · 2025/03/06(木) 16:04:15.79

どのCだよ……

**デフォルトの名無しさん** · 2025/03/06(木) 21:03:06.28

>>967
一般的には 32bit 環境からの互換性のためにそうなってる
ただ言語仕様としてそれが規定されているわけではない
明示的に 64bit 整数を使いたいなら int64_t とかを使う

**デフォルトの名無しさん** · 2025/03/06(木) 21:11:47.39

LSI-C試食版

**デフォルトの名無しさん** · 2025/03/06(木) 21:23:51.69

>>967
補足。ちなみに 64bit 環境で size_t や sizeof が 64bit unsigned になったのは
アドレス空間の伸長により 32bit 長を超える配列や構造体が (実用性はともかく) 定義出来るようになったから

**デフォルトの名無しさん** · 2025/03/06(木) 22:54:13.31

SHARCだとcharも32bit w

**デフォルトの名無しさん** · 2025/03/06(木) 23:24:05.48

>>967
LLP64
long longとポインターが64bit
Windowsはこっち

LP64
longとlong longとポインターが64bit
Unix系はこっち

**デフォルトの名無しさん** · 2025/03/07(金) 03:26:30.77

規格ではサイズの保証なんか全く無いからstdint.h使えって書こうとしたけどそういやWin32スレだった

**デフォルトの名無しさん** · 2025/03/07(金) 08:52:50.74

なんでlongとintが同じなんだよって昔から思ってるけど、まぁ今更

**デフォルトの名無しさん** · 2025/03/07(金) 12:13:30.16

int64_tはあるのにint32_tが無いのは何故

**デフォルトの名無しさん** · 2025/03/07(金) 12:50:01.21

stdint.h(20):
typedef int int32_t;

警備員[Lv.4][新芽] · 2025/03/07(金) 20:55:06.07

前後にいろいろあるでしょ
ILP64ってのもあるし

**デフォルトの名無しさん** · 2025/03/08(土) 20:22:43.73

ファイルからそのファイルのハンドル握ってるプロセスを特定する事って可能？
プロセスが握ってるハンドルを列挙していく事はntdll利用したら可能だからその方法で結果的に上記の目的は達成できるっちゃできるんだけど、逆方向から出来たほうが工程は減りそうだから可能なら教えてもらいたい

**デフォルトの名無しさん** · 2025/03/08(土) 21:37:29.02

performance meter

**デフォルトの名無しさん** · 2025/03/12(水) 22:20:50.10

>>979
自己レスだけど全排他ロックされたファイルもCreateFile(path, 0, 0, NULL, OPEN_EXISTING, FILE_READ_ATTRIBUTES, NULL);で開けるんだね
ハンドルさえ得られればNtQueryInformationFileのFILE_INFORMATION_CLASSで簡単にハンドル握ってるプロセス列挙出来た

**デフォルトの名無しさん** · 2025/03/12(水) 22:22:14.84

FILE_INFORMATION_CLASSじゃなくてFILE_INFORMATION_CLASS::FileProcessIdsUsingFileInformationで列挙できた

**デフォルトの名無しさん** · 2025/03/12(水) 22:30:58.42

>>981
CWDがBのプロセスpが居てAフォルダをリネームや移動する場合はAのハンドルでpが分かるの？
/A/B/

**デフォルトの名無しさん** · 2025/03/12(水) 22:32:30.39

CWDでなくて
PWDね

**デフォルトの名無しさん** · 2025/03/12(水) 22:36:31.70

Process Explorerで見る限りは、プロセスpのハンドル一覧にはAのハンドルは見えないけど...

**デフォルトの名無しさん** · 2025/03/13(木) 07:40:49.73

>>985
リネームや移動はハンドル握ってるタイミングが一瞬だから見えないだけでは？
作業フォルダってだけだとハンドルを握ってる訳ではないだろうし

**デフォルトの名無しさん** · 2025/03/13(木) 12:00:07.35

>>986
> 作業フォルダってだけだとハンドルを握ってる訳ではないだろうし
win32 API使ったプログラム書けるのだったら確認したら良いのに...

**デフォルトの名無しさん** · 2025/03/13(木) 12:50:16.04

>>983に言えよ

**デフォルトの名無しさん** · 2025/03/13(木) 13:15:20.89

>>988
急にどうした？雰囲気悪くするだけだぞ

**デフォルトの名無しさん** · 2025/03/13(木) 13:19:04.13

そもそも979が質問はするけど人からの質問には答えないタイプに見えるからそこからだな、雰囲気改善は

**デフォルトの名無しさん** · 2025/03/13(木) 13:23:53.41

言った手前、横から答えて置くかな

>>979 FileTest.exeがよく使われている
>>983 その場合pはリストアップされない
>>986 作業フォルダはhandleとして握っている
>>988 一連の流れの誰ですか？

**デフォルトの名無しさん** · 2025/03/13(木) 13:40:50.24

>>990
別にちゃんと答えてるけど？
で、確認してみたらProcessHackerではカレントディレクトリのハンドルは普通に見えるね
てか手順教えてるんだからツールに頼らずにそれこそ確認したい側が>>981をやってみたらいいと思うけど

**990** · 2025/03/13(木) 14:39:30.31

ごめん、986の感じから981~983の流れが全く通ってないから981とは別人に見えた

確認したい側が手を動かすのは原則だけど、既に下準備が整っているのだからちょっとした便乗質問には答えてあげるのが助け合いの精神だな
もっとも986時点では作業フォルダを握っている前提で983を見てなかったからやむなしか

で>>988は誰よ？

**990** · 2025/03/13(木) 14:41:07.70

>>983
フォルダを開く時はFILE_FLAG_BACKUP_SEMANTICSな

**デフォルトの名無しさん** · 2025/03/13(木) 15:58:51.91

誰でもねぇよただのスレ見てるだけの人間だ
誰かじゃねぇと発言すらできねぇのかよ
つーかお前こそ誰だよｗ

**デフォルトの名無しさん** · 2025/03/13(木) 16:02:25.92

ついでに次スレ建てといた

Win32API質問箱 Build128
https://mevius.5ch.net/test/read.cgi/tech/1741849188/

**990** · 2025/03/13(木) 16:08:57.63

>> ID:fUgksTzw
スレ立て乙
ただの荒らしだと思ったが見直したぞ
仲良く行こう

**デフォルトの名無しさん** · 2025/03/13(木) 18:44:47.29

>>993
お前は誰なんだ

**デフォルトの名無しさん** · 2025/03/13(木) 19:05:51.90

だーれだ？

**デフォルトの名無しさん** · 2025/03/13(木) 19:18:50.54

キチガイ

**1001** · Over 1000

このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 1189日 21時間 45分 55秒