Win32API質問箱 Build127
その為のレジストリなんじゃないのか？
キーは基本的に会社名含めてるから被らないし、ファイルを作成して消耗するより楽だろ テンポラリの作業用にレジストリ使うの？
ファイル造る方が楽 >>753とか>>754とか
世の中に同じ名前の会社が一切存在しないと思ってんだろうか ファイルやディレクトリ造るために社名変更するまである >>750
>確かにそれを言い出したら、インストール時も、
>Program Filesの中に同名のファイルがあったらどうするんだとか出てきますが。
Windows Installerは排他実行だった気がする。 >>750
>確かにそれを言い出したら、インストール時も、
>Program Filesの中に同名のファイルがあったらどうするんだとか出てきますが。
Windows Installerは排他実行だった気がする。 リソースの作成は、片山さんのを使っているのですか？ MoveFileExにはMOVEFILE_WRITE_THROUGHというフラグがあって、
直後にディスクへフラッシュすることができるけど、
これと同じことをCopyFileで行うことはできますか？ >>771
Microsoft公式で、こんな苦し紛れな方法が紹介されているんですね。
MoveFileExはNT3.1以降の関数なのに。 >>770,771
どっちもそれだけでは不意の電源断でロバストじゃないのが難しい。 タイムスタンプが1970年だかのファイルを仮置きして別名でコピーしたら挿げ替え
電源断が怖いなら挿げ替え部分だけアトミックに作ればいい >>774
>電源断が怖いなら挿げ替え部分だけアトミックに作ればいい
この部分は具体的にセオリー的なやり方があるのですか？
挿げ替えで思い当たるReplaceFileはアトミックか分かりませんでした。 CopyFileではいったんテンポラリファイルにコピーして、
それをMoveFileExで正しいファイル名に変更するとかやれば、
ちゃんと書き込まれる可能性は高くなるんですかね >>775
Rep略はアトミックだよ
MSのどっかに書いてあった RtlReAllocateHeap(GetProcessHeap(), 0, lpMem, dwBytes)
これをそこそこの頻度でやってると特定回数目にクラッシュしてしまうんだけどどういうことなのだろうか
よくある戻り値null未チェックとかそういう事ではなく上記関数内で落ちるんだよね
lpMemも間違いなく生きてるメモリなのは確認済みでdwBytesも不自然な値ではない
呼び出し方が悪いのかと思ってmalloc、reallocに変えてみてもやはり同様の場所でクラッシュしてしまう API変えても発生するならAPI関係ない場所のお前のバグじゃん >>781
WindowsのreallocはHeapReAllocのラッパーでHeapReAllocの実態はRtlReAllocateHeapへのリンクに過ぎない訳だが mallocやreallocもまともに使えない子はこのスレに来るのはまだ早かったねー free 済のポインタに対して 再び free したんじゃないの？ 特定回数でクラッシュするなのがわかってるなら
アドレスがどう変化した時にクラッシュするとかわかりそうなもんだ mallocで大きなメモリを取得して、その領域から切り出すalloc関数などを作って差し替えてデバッグするとか？
組み込み系で良くやるけどね。 >>786
それはおかしいだろ
(アドレスが変わる場合は)freeする前に新しいアドレスに内容コピーしないといかんから BoundsChecker か PURIFY ですぐ究明できそうな気がするけど メモリのフラグメンテーションで大きい領域がとれないんじゃない？ ファイルパスなんかはカーネルが結局UNICODE_STRINGとして扱うからwchar版の方がパフォーマンス良いけどadvapi32のレジストリ系関数はどうなんだろうか？ WM_MOUSEFIRSTからWM_MOUSELASTのメッセージって、
これから追加されるメッセージもLPARAMはすべてマウス位置のクライアント座標が入る、という約束はありますか？ Spy++のメッセージウィンドウには、「S」や「P」の文字が表示されていて、
それがSendで送られたのかPostで送られたのかがわかるようになっていますが、
これと同じ区別を、自身のメッセージハンドラ上で行うことはできるのでしょうか
InSendMessageというAPIは見つけたのですが、
Spy++で「S」と表示されるものでも0が返ってきてしまいました InSendMessageは別のスレッドからSendMessageされたかを判断する、と説明があるから、
単純にSendMessage呼び出しを判定するものではなさそう
同一スレッドからのSendMessageの呼び出し判定は、ウィンドウプロシジャのコールスタック辿って
SendMessageのエントリポイントと比較するとか、何か追加で頑張る必要がありそう Snedはメッセージキューに来ないからあればPostなければSendやぞ 内部でIsPostMsgとかフラグ作ってDispatchMessage()を呼ぶ時に１にする終わったらゼロにする Postでキューに入ったのを取り出して呼ばれるのはそこだけでしょう
Sendでは直接呼ばれる
もしウィンドウプロシージャの中からSendしてたらこれは使えない 自アプリ側で予め
SendMessage PostMessage
をフックしとけば良いのでは？ >>796-803
ありがとうございます
Spy++はメッセージをフックしているから、SendとPostの区別もできるということなんですかね 自作アプリに対してSendMessageでWM_APP送ってるけど送れてない（受信できていない）ことがあったので
送信側でGetLastErrorしたら
> 0x05：アクセスが拒否されました。
が取れました。
ここによると
ttps://learn.microsoft.com/ja-jp/windows/win32/api/winuser/nf-winuser-sendmessage
> メッセージが UIPI によってブロックされると、 GetLastError で取得された最後のエラーは 5 (アクセス拒否) に設定されます。
これに該当してる？のか他の原因でアクセス拒否されているのか分からないけど、
受け側のアプリはずっと起動したままで直前までメッセージ受信できていたことと、
その後もアプリが死んでいるようには見えず操作できるし動作ログも残るため、
ただただWM_APPメッセージ受信のみ（？）できなくなっているような状況です。
ここで質問ですが、どういう時に急にメッセージ受信できなくなるのか、エスパーお願いします。
今後の対策としては受信側でChangeWindowMessageFilterを使ってWM_APPを許可すれば良さそうだと当たりは付けていますが・・
権限レベルを弄ったりということは一切していないので、問題の発動条件が知りたいです。 んで、この手のシステムからの意図しない介入問題が起きた場合は、
原則プロセスの再作成で解決するしかない これはLow Level Hookが外れた時の対処と同じ
恐らくSendMessageの処理が規定時間以内に終わらなかったとかで適当に介入してるんだろう
知らんけど >>808
再現性ないと言っていいのか、手元では再現できず
エラーが出た環境でも普段は問題出てなくて、たまたま問題が出たのに気付いてログを漁ってエラーコードが分かり、
過去ログも遡ると半月前にも一度エラーが出ていたのは分かりました
この問題が出た環境は24時間PC&アプリ起動しっぱなしということらしく、その時点で
何となくお察し感がなくもないですが原因ははっきりさせたいなと
>>809-810
受信側は一切メッセージの受信を感知していない（ログに全く残らない）ようなので
規定時間以内に終わっていないというようなことではないとは思いますが、
何かしらの原因で適当に介入されている感はすごくあります
まあ適当に〜されたとしても、はっきりしたいところです 断片化回避のためにSetFilePointer -> SetEndOfFile -> SetFilePointerサンドイッチってもう古いやり方？
.NETのFileIO実装がSetFileInformationByHandle(FILE_ALLOCATION_INFO)でやってるんだが >>811
ちょっと調べてはみたけどstackoverflowでも迷宮入りしててだめだったんよね
SYSTEMプロセスから送れば拒否られないとは思うが
確実にプロセス間通信をしたかったらメッセージよりは名前付きパイプが無難だろうな >>815
迷宮入りまで調べてくれてたんですね
確かにパイプが無難です
今さらコイツを修正するには作り直しレベルなのでもう無理ですがｗ
とりあえずしばらく放置して色々な環境でログ収集して情報整理します
ありがとうございました >>807
再現性はともかくとして、SendMessageが途中から拒否られる事象がOSのどのバージョンで発生したか書いといてくれると嬉しい >>817
どうもすみません
Windows11 home 23H2です
ちょうど今おかしな環境のPCがまたおかしくなっているようなので調べていましたが、
受信側プロセスが管理者特権に変更されているようで、これが原因ですね
送信側は管理者特権は付与されていませんが、送信側プロセスから受信側プロセスを
起動していますから、最初は特権が付与されていないはず・・・
ということでどちらのプロセスも再起動させたところ、どちらも標準ユーザーになっていました
explorerからexeプロパティを見ても管理者権限はチェックされていないようです
意図せず途中で管理者特権が付与される可能性はあるのでしょうか？
（プログラム的にはそんなことしているつもりはもちろん無いですが） 無意識にそんな特権付与されたら怖すぎるがなｗ
システムが一時的に特殊な状態にしてるんじゃないの APIの先で起動されるスレッド（OSが起動する）が管理者特権付きで
それがアクティブな瞬間はプロセスが管理者特権付きに見えて、
そんなタイミングのプロセスに一般ユーザがメッセージ送ると、
管理者様に対して頭が高いぞってアクセスデナイド。
とか想像してみた。 818です
ログを見ると、一度メッセージ受信できなくなるとずっと受信できていないようです
管理者特権が付いているのを確認したのはタスクマネージャでの目視ですが、
見たところずっと特権がついているのでタイミングの問題ではなく、何かしらの拍子で特権がついたまま
という感じですね
今のところ、24時間起動したまま使い続けていますがあれから特権はついていません
特権を必要とするようなコードを書いたことない（つもり）なので、原因にたどり着くのは中々難しい状況です
例えば、どんなことをすると特権が付与される（UIもなく勝手に？）のでしょう？ 心当たりが無いなら今月のCVE-2024-30051だとか特権の昇格の脆弱性のどれかに引っかかってる可能性あり >>813
自己レスだけどSetFileInformationByHandle(hFile, FileAllocationInfo...)でやるとサイズが小さい場合にMFT内にデータ埋め込んで完結する場合でも1セクタ確保されてしまうようなので旧来の方法でやる方が無難だった >>813
埋め込みサイズ上限を上回る新規ファイルを作る場合ならハンドル作成時にアロケーションサイズも同時指定する方が良さそう >>807,821
疑ってすまないけど、本当に隅から隅まで自分で書いたプログラムなのか？
OSSをちょっと弄った程度で自作アプリと言っているだけなんじゃないか？ リストビューで範囲選択したときの青い枠の色や内部の半透明な色の値は、APIで取得できるのでしょうか この辺りlinuxやMacのWMとかと違って有る程度の値の取得変更できるのはWindowsの強みだったよな >>828
GetSysColorはRGBの値で、透明度の値まで持ったものを返すようには見えなかったのですが、
具体的にどのパラメータを指定するのでしょうか？ 他スレでスクリーンショットのマルチポストがあるけど、加えてコントロールの色を取得か
AIに食わせるUI Automation学習データを整備してるのかな >>832
XPの頃からある範囲選択時の半透明の青なのですが >>833
プログラム組んでるのなら自分で逆算しろ >>834
どのWindowsでも画面設定とか関係なくこの青なら直値で計算してもいいけど、
なにかのAPIで取得できるなら合わせておきたいです 稀によく自分で手を動かすのと人に訊く比率がバグってる奴がいるよな
本人は自覚があるから分散してるつもりだろうけど一回そう思われたら終わりなんだよ
職場で塩対応されてるんだろうな >>835
GetThemeColor じゃだめ？ COLOR_HIGHLIGHTとCOLOR_HIGHLIGHTTEXTじゃないの？ 
